Re: [ANN] Instaparse 1.0.0
Man, this looks like pure gold!
Le mardi 9 avril 2013, Mark Engelberg a écrit :
Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
The two stand-out features:
1. Converts standard EBNF notation for context-free grammars into an
executable parser. Makes the task of building parsers as lightweight and
simple as working with regular expressions.
2. Works with *any* context-free grammar. This means you don't have to
learn the esoteric subtleties of LR, LL, LALR or any other specialized
subset. Left-recursion, right-recursion, ambiguous grammars -- instaparse
handles it all.
Example:
(def as-and-bs
(parser
S = AB*
AB = A B
A = 'a'+
B = 'b'+))
= (as-and-bs abbbbb)
[:S
[:AB [:A a a a a a] [:B b b b]]
[:AB [:A a a a a] [:B b b]]]
https://github.com/Engelberg/instaparse for full feature list and
extensive tutorial.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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: Opinions on Equality Semantics
One reason for being slightly impure here is for greater java interoperability. Clojure gets much of its equality semantics for collections from java.lang.List and java.lang.Set, which define equality to depend only on collection contents and not on concrete type. By having equality semantics which match up, you can pass a clojure vector, list, or seq to a library expecting a j.l.List. (it's a little more complicated than this; clojure defines its own equality semantics which broadly matches java collection semantics using the .equiv() method. It differs only in which numeric types it considers equal. The clojure = function calls .equiv if present, and .equals otherwise. But broadly clojure's equality matches java collection equality.) On Apr 9, 2013 12:02 AM, JvJ kfjwhee...@gmail.com wrote: This is just an idle curiosity up for discussion, but in Clojure, if (= a b) is true, then given some function f, it is not necessarily true that (= (f a) (f b)) For instance: (defn check-eq [f a b] [(= a b) (= (f a) (f b))]) (check-eq #(conj % 1) '(1 2 3) [1 2 3]) [true false] Even though the behaviour of lists and vectors differs under specific functions, they still count as equal, but this statement If a = b, then (f a) = (f b) seems like it would be some sort of rule or axiom about functional programming. What's the FP purists' view on this? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
Mark Engelberg mark.engelb...@gmail.com writes: Hi Mark, Example: (def as-and-bs (parser S = AB* AB = A B A = 'a'+ B = 'b'+)) Nice, but providing the grammar as a plain string looks somewhat unnatural to me. Why not something like this (parser being a macro)? (def as-and-bs (parser S = AB* . AB = A B . A = a + . B = b + .)) I.e., symbols denote non-terminals, strings denote terminals, and the dot indicates the end of a rule. Bye, Tassilo -- -- 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.
Something goofy you can do in Clojure.
This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- 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: Opinions on Equality Semantics
JvJ kfjwhee...@gmail.com writes: This is just an idle curiosity up for discussion, but in Clojure, if (= a b) is true, then given some function f, it is not necessarily true that (= (f a) (f b)) I think this axiom isn't true in any language. Take `str` / toString() as an example. If that statement was true, then equal objects would need to have equal string representations. Then you either couldn't have 1 and 1.0 be equal, or you would need to print all numbers as floats. An even better counter example are sets versus sorted sets. Bye, Tassilo -- -- 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] Instaparse 1.0.0
On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn t...@gnu.org wrote:
Nice, but providing the grammar as a plain string looks somewhat
unnatural to me. Why not something like this (parser being a macro)?
(def as-and-bs
(parser
S = AB* .
AB = A B .
A = a + .
B = b + .))
I.e., symbols denote non-terminals, strings denote terminals, and the
dot indicates the end of a rule.
Bye,
Tassilo
I played around with that, but even if you suppress evaluation by using a
macro, Clojure's reader makes strong assumptions about certain symbols.
For example, it is standard in EBNF notation for {} to mean zero-or-more.
But if you include {A B C} in your grammar using the macro approach,
Clojure's reader will throw an error because it treats {} as a map and
expects an even number of forms to follow. That was the main reason, but
it also makes the notation much more sensitive to whitespace (for example,
AB * versus AB*). Gradually, those little issues start making it look less
and less like traditional notation. There's something really nice about
just being able to copy and paste a grammar off of a website and have it
just work.
I understand where you're coming from, though. It definitely is part of
the Clojure culture to avoid string representations for many kinds of data
(e.g., SQL queries). We do accept it for regular expressions, and for
things like #inst 2011-12-31T19:00:00.000-05:00, though, and that's the
kind of feel I was going for. Would it be more psychologically palatable
to type:
#insta/parser S = 'a' 'b'
rather than
(insta/parser S = 'a' 'b')
?
What do you think would be gained by making it a macro? From my
perspective, a macro is essentially just a string that is being processed
by the Clojure reader (and thus subject to its constraints). If the
grammar were expressed in the way you propose, is it any easier to build up
a grammar programmatically? Is it any easier to compose grammars? If
anything, I think it might be harder.
Thanks for the comments,
Mark
--
--
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: Something goofy you can do in Clojure.
What version are you running? As far as I know, .3 isn't even a valid representation for a number -- you'd have to write it as 0.3. So I'm not sure where you're running that code snippet such that you don't get an immediate error. On 1.5.1: = (+ 0.3 1.7) 2.0 That said, I think most programmers know that floating point representations of numbers are inexact. That's why, if you care about exactness, you should write: = (+ 0.3M 1.7M) 2.0M On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey cgree...@gmail.com wrote: This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- 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: Something goofy you can do in Clojure.
Hey Mark, don't get paranoid :)... this is all Cedric did! user= (def .3 0.4) #'user/.3 user= (+ .3 1.7) 2.1 Jim On 09/04/13 10:46, Mark Engelberg wrote: What version are you running? As far as I know, .3 isn't even a valid representation for a number -- you'd have to write it as 0.3. So I'm not sure where you're running that code snippet such that you don't get an immediate error. On 1.5.1: = (+ 0.3 1.7) 2.0 That said, I think most programmers know that floating point representations of numbers are inexact. That's why, if you care about exactness, you should write: = (+ 0.3M 1.7M) 2.0M On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey cgree...@gmail.com mailto:cgree...@gmail.com wrote: This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- 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 mailto: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 mailto:clojure%2bunsubscr...@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 mailto:clojure%2bunsubscr...@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: Something goofy you can do in Clojure.
In Clojure 1.5.1: = (+ .3 1.7) CompilerException java.lang.RuntimeException: Unable to resolve symbol: .3 in this context, compiling:(NO_SOURCE_PATH:1:1) So the only way you can do this is if you def'd .3 before = (def .3 0.4) = (+ .3 1.7) 2.1 On Tuesday, April 9, 2013 10:53:06 AM UTC+2, Cedric Greevey wrote: This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- 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] Instaparse 1.0.0
Am Dienstag, 9. April 2013 11:41:38 UTC+2 schrieb puzzler:
On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn ts...@gnu.org
javascript:wrote:
Nice, but providing the grammar as a plain string looks somewhat
unnatural to me. Why not something like this (parser being a macro)?
(def as-and-bs
(parser
S = AB* .
AB = A B .
A = a + .
B = b + .))
I played around with that, but even if you suppress evaluation by using a
macro, Clojure's reader makes strong assumptions about certain symbols.
For example, it is standard in EBNF notation for {} to mean zero-or-more.
But if you include {A B C} in your grammar using the macro approach,
Clojure's reader will throw an error because it treats {} as a map and
expects an even number of forms to follow. That was the main reason, but
it also makes the notation much more sensitive to whitespace (for example,
AB * versus AB*). Gradually, those little issues start making it look less
and less like traditional notation. There's something really nice about
just being able to copy and paste a grammar off of a website and have it
just work.
What about something like this, a little like enlive does encode selectors?
(insta/parser :S [:AB :*] :AB [:A :B] :A [a :*] :B [b :*])
-billy.
--
--
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] Instaparse 1.0.0
On Tue, Apr 9, 2013 at 2:41 AM, Mark Engelberg mark.engelb...@gmail.comwrote: What do you think would be gained by making it a macro? From my perspective, a macro is essentially just a string that is being processed by the Clojure reader (and thus subject to its constraints). If the grammar were expressed in the way you propose, is it any easier to build up a grammar programmatically? Is it any easier to compose grammars? If anything, I think it might be harder. I should also point out, for anyone who hasn't had a chance to read through the tutorial, that instaparse does include a combinator interface that lets you build the parsers entirely through functions. The way I look at it is that if you're going for human writing and readability, it's hard to beat strings (or reading from a resource file), and if you're going for a grammar that will be generated by a program, it's hard to beat functions. So both are included. But targeting some sort of functional-ish looking thing that doesn't look quite right and doesn't compose effectively -- that doesn't seem to serve either purpose well. -- -- 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: Something goofy you can do in Clojure.
Technically, this is a user error, since . (dot) is not a valid character inside user-defined symbols. Clojure does mostly take the stance that it is a sharp tool and you are allowed to cut yourself, should you really want to. See http://clojure.org/reader for reference, especially these two sentences : Symbols begin with a non-numeric character and can contain alphanumeric characters and *, +, !, -, _, and ? Symbols beginning or ending with '.' are reserved by Clojure. On 9 April 2013 11:51, Niels van Klaveren niels.vanklave...@gmail.comwrote: In Clojure 1.5.1: = (+ .3 1.7) CompilerException java.lang.RuntimeException: Unable to resolve symbol: .3 in this context, compiling:(NO_SOURCE_PATH:1:1) So the only way you can do this is if you def'd .3 before = (def .3 0.4) = (+ .3 1.7) 2.1 On Tuesday, April 9, 2013 10:53:06 AM UTC+2, Cedric Greevey wrote: This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
Looks awesome. Would it be possible to plug in support for the ABNF[1] notation that the IETF use? Might be useful for implementing standards. Mostly just a different syntax for repetition, and has support for comments. [1] http://www.rfc-editor.org/std/std68.txt -- Dave -- -- 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: Opinions on Equality Semantics
Since Clojure is not a pure language, you cannot even expect (a == a) == ((f a) == (f a)), so I do not think it is a stretch to break that theorem for b != a. Most importantly, Clojure's notion of equality is centered around the notion of simple data, irrespective of the specific type of object you have built to encapsulate it. On 9 April 2013 11:00, Tassilo Horn t...@gnu.org wrote: JvJ kfjwhee...@gmail.com writes: This is just an idle curiosity up for discussion, but in Clojure, if (= a b) is true, then given some function f, it is not necessarily true that (= (f a) (f b)) I think this axiom isn't true in any language. Take `str` / toString() as an example. If that statement was true, then equal objects would need to have equal string representations. Then you either couldn't have 1 and 1.0 be equal, or you would need to print all numbers as floats. An even better counter example are sets versus sorted sets. Bye, Tassilo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
I am not convinced that typing more delimiter characters is a better thing.
The string representation is ... shorter and less error prone.
As Mark said, a string isolates you from the reader which could change
its behavior over time introducing other undesirable side effects like {}
with an uneven # of args.
Thank you for this parser Mark, it's just in time, I have a need for this that
came to life a week ago :) Will definitively try this in the next month or so.
Luc P.
Mark Engelberg mark.engelb...@gmail.com writes:
Hi Mark,
Example:
(def as-and-bs
(parser
S = AB*
AB = A B
A = 'a'+
B = 'b'+))
Nice, but providing the grammar as a plain string looks somewhat
unnatural to me. Why not something like this (parser being a macro)?
(def as-and-bs
(parser
S = AB* .
AB = A B .
A = a + .
B = b + .))
I.e., symbols denote non-terminals, strings denote terminals, and the
dot indicates the end of a rule.
Bye,
Tassilo
--
--
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.
--
Softaddictslprefonta...@softaddicts.ca 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: [ANN] Instaparse 1.0.0
Thanks for the suggestion. I based the syntax off of EBNF, and hadn't run across ABNF notation before your link just now. It shouldn't be too hard to add support for ABNF's repetition syntax and comments. Getting the semantics of the terminal values to precisely match the ABNF spec seems like more effort -- how essential is that piece do you think, versus just using strings and regexes for the terminals? Support for comments in the EBNF notation is probably a good idea too. On Tue, Apr 9, 2013 at 3:29 AM, David Powell djpow...@djpowell.net wrote: Looks awesome. Would it be possible to plug in support for the ABNF[1] notation that the IETF use? Might be useful for implementing standards. Mostly just a different syntax for repetition, and has support for comments. [1] http://www.rfc-editor.org/std/std68.txt -- Dave -- -- 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: Something goofy you can do in Clojure.
Ah. That's pretty funny :) On Tue, Apr 9, 2013 at 2:48 AM, Jim foo.bar jimpil1...@gmail.com wrote: Hey Mark, don't get paranoid :)... this is all Cedric did! user= (def .3 0.4) #'user/.3 user= (+ .3 1.7) 2.1 Jim On 09/04/13 10:46, Mark Engelberg wrote: What version are you running? As far as I know, .3 isn't even a valid representation for a number -- you'd have to write it as 0.3. So I'm not sure where you're running that code snippet such that you don't get an immediate error. On 1.5.1: = (+ 0.3 1.7) 2.0 That said, I think most programmers know that floating point representations of numbers are inexact. That's why, if you care about exactness, you should write: = (+ 0.3M 1.7M) 2.0M On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey cgree...@gmail.com wrote: This may look mildly surprising, and suggests one more thing *not* to ever do in production code: user= (+ .3 1.7) 2.1 user= :) Shouldn't be hard to figure out how to put a repl in a state where that expression will evaluate to that result. I'm sure mathematicians everywhere are deeply offended by the clojure reader now. :) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Signing libraries on clojars
Most probably it is waiting for you to enter the passphrase to unlock your private key. You should be seeing a message to that effect, though. On Monday, April 8, 2013 11:42:20 AM UTC+2, puzzler wrote: When I do lein deploy clojars, the tool hangs after reporting that it has created the jar. Any idea what might be causing it to hang? On Fri, Apr 5, 2013 at 7:19 PM, Nelson Morris nmo...@nelsonmorris.netjavascript: wrote: Yep. There is an issue for making it work over scp, which the lein-clojars plugin uses, at https://github.com/ato/clojars-web/issues/118. Unfortunately the commits mentioning they fix it are incorrect. At the moment, `lein deploy clojars` is the way to send signatures. This command is built in to lein 2.x. - Nelson On Fri, Apr 5, 2013 at 8:35 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: I'm not sure Clojars supports sending signatures over scp yet. You might need to do an HTTP deploy with `lein deploy`. The docs around this are a bit scarce; sorry about that. Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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 javascript:. 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 clo...@googlegroups.comjavascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
I find this library very exciting. It is incredibly well documented, already covers a broad range of use cases, I can't wait for trying it. There are also a lot of interesting ideas that may pollinate outside it, I love the cross-pollination capability of open source software ! (i.e. I'd love to see some of these features into parsley). Do you have a roadmap for the next releases ? Of interest to me: - restartable version ? (probably doable, if internal implementation uses immutable datastructures) - incremental version ? (Dunno if that's an easy one, and way beyond my current programming skills anyway to be able to even judge) - possibility to have transform-map(s) passed as an argument to parse, so that a collection of views can be applied in parallel and the tree be traversed once ? Have you tried some tests to compare performance with e.g. same grammars in Antlr ? Thanks again for the hard work, -- Laurent 2013/4/9 Mark Engelberg mark.engelb...@gmail.com: Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The two stand-out features: 1. Converts standard EBNF notation for context-free grammars into an executable parser. Makes the task of building parsers as lightweight and simple as working with regular expressions. 2. Works with *any* context-free grammar. This means you don't have to learn the esoteric subtleties of LR, LL, LALR or any other specialized subset. Left-recursion, right-recursion, ambiguous grammars -- instaparse handles it all. Example: (def as-and-bs (parser S = AB* AB = A B A = 'a'+ B = 'b'+)) = (as-and-bs abbbbb) [:S [:AB [:A a a a a a] [:B b b b]] [:AB [:A a a a a] [:B b b]]] https://github.com/Engelberg/instaparse for full feature list and extensive tutorial. -- -- 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.
Basic multiplication incorrent?!?
Can anyone explain me please why I get: Clojure 1.5.1 user= (* 148.52 0.0256) 3.80211206 The correct result should be: https://www.google.com/search?q=148.52+*+0.0256 3.802112 If you don't believe me try it on: http://tryclj.com/ thx Bost -- -- 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: Basic multiplication incorrent?!?
Nothing weird there. Looks like an usual floating point operation. On Tue, Apr 9, 2013 at 9:27 AM, Rostislav Svoboda rostislav.svob...@gmail.com wrote: Can anyone explain me please why I get: Clojure 1.5.1 user= (* 148.52 0.0256) 3.80211206 The correct result should be: https://www.google.com/search?q=148.52+*+0.0256 3.802112 If you don't believe me try it on: http://tryclj.com/ thx Bost -- -- 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: Basic multiplication incorrent?!?
This article explains better how it works: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems Regards Plínio On Tue, Apr 9, 2013 at 9:27 AM, Rostislav Svoboda rostislav.svob...@gmail.com wrote: Can anyone explain me please why I get: Clojure 1.5.1 user= (* 148.52 0.0256) 3.80211206 The correct result should be: https://www.google.com/search?q=148.52+*+0.0256 3.802112 If you don't believe me try it on: http://tryclj.com/ thx Bost -- -- 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: Basic multiplication incorrent?!?
On 9 April 2013 14:27, Rostislav Svoboda rostislav.svob...@gmail.com wrote: Can anyone explain me please why I get: Clojure 1.5.1 user= (* 148.52 0.0256) 3.80211206 The correct result should be: https://www.google.com/search?q=148.52+*+0.0256 3.802112 Plínio's answer is correct, but just to demonstrate this is not just Clojure doing something stupid, here's Python doing the same thing: Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. 148.52 * 0.0256 3.80211206 and here's how you should be able to get exact values in Clojure: user= (* 148.52M 0.0256M) 3.802112M If you don't believe me try it on: http://tryclj.com/ thx Bost -- Michael Wood esiot...@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 --- 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: Basic multiplication incorrent?!?
I see. I did some testing. It's not clojure, it's not java, it's deeper. People of planet Earth! Stop wasting time on SETI if your machines can't properly calculate 148.52 * 0.0256 !!! -- -- 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: Basic multiplication incorrent?!?
In languages that doesn't give you support to arbitrary precision like Clojure do, it's a usual practice compare values using round functions. In pseudo-C it would be like that: float a = 148.52 * 0.0256; float b = 3.802112; a == b; = false round(a, 5) == round(b, 5); = true Or, if possible, don't use float type. I saw some coworkers spend a whole night debugging until they figured that float trick. On Tue, Apr 9, 2013 at 10:17 AM, Rostislav Svoboda rostislav.svob...@gmail.com wrote: I see. I did some testing. It's not clojure, it's not java, it's deeper. People of planet Earth! Stop wasting time on SETI if your machines can't properly calculate 148.52 * 0.0256 !!! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
2013/4/9 Laurent PETIT laurent.pe...@gmail.com I find this library very exciting. It is incredibly well documented, already covers a broad range of use cases, I can't wait for trying it. I concur. Thank you Mark for not letting your users down and writing the docs. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Instaparse 1.0.0
Mark Engelberg mark.engelb...@gmail.com writes:
Hi Mark,
(def as-and-bs
(parser
S = AB* .
AB = A B .
A = a + .
B = b + .))
I played around with that, but even if you suppress evaluation by
using a macro, Clojure's reader makes strong assumptions about certain
symbols. For example, it is standard in EBNF notation for {} to mean
zero-or-more. But if you include {A B C} in your grammar using the
macro approach, Clojure's reader will throw an error because it treats
{} as a map and expects an even number of forms to follow.
Indeed, I didn't think about this one.
That was the main reason, but it also makes the notation much more
sensitive to whitespace (for example, AB * versus AB*). Gradually,
those little issues start making it look less and less like
traditional notation. There's something really nice about just being
able to copy and paste a grammar off of a website and have it just
work.
That's nice.
I understand where you're coming from, though. It definitely is part of
the Clojure culture to avoid string representations for many kinds of data
(e.g., SQL queries). We do accept it for regular expressions, and for
things like #inst 2011-12-31T19:00:00.000-05:00, though, and that's the
kind of feel I was going for. Would it be more psychologically palatable
to type:
#insta/parser S = 'a' 'b'
rather than
(insta/parser S = 'a' 'b')
?
No, not really.
What do you think would be gained by making it a macro?
I don't really care if it's a macro or a function, but if the grammar
was represented using symbols, keywords, and clojure collections, you'd
get at least a bit syntax highlighting and maybe a bit support for
indentation or refactoring.
From my perspective, a macro is essentially just a string that is
being processed by the Clojure reader (and thus subject to its
constraints). If the grammar were expressed in the way you propose,
is it any easier to build up a grammar programmatically? Is it any
easier to compose grammars? If anything, I think it might be harder.
I think it would be nice if grammars were expressed in a format
processable by Clojure in the very same respect as why homoiconicity in
general is a strength of Lisps.
FWIW, the Bison equivalent Emacs Lisp parser Wisent uses grammars
represented as s-exps.
http://www.gnu.org/software/emacs/manual/html_node/wisent/Grammar-format.html#Grammar-format
IMHO, it would be cool if a clojure parser library would use a similar
format (exploiting clojure data structures beyond lists where they make
sense), at least internally. Of course, one could still have other
frontends like for the EBNF you are using which would be translated to
the internal format.
Bye,
Tassilo
--
--
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] Instaparse 1.0.0
That looks stunning - congrats and thanks! On Apr 9, 2013, at 1:18 AM, Mark Engelberg wrote: Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The two stand-out features: 1. Converts standard EBNF notation for context-free grammars into an executable parser. Makes the task of building parsers as lightweight and simple as working with regular expressions. 2. Works with *any* context-free grammar. This means you don't have to learn the esoteric subtleties of LR, LL, LALR or any other specialized subset. Left-recursion, right-recursion, ambiguous grammars -- instaparse handles it all. Example: (def as-and-bs (parser S = AB* AB = A B A = 'a'+ B = 'b'+)) = (as-and-bs abbbbb) [:S [:AB [:A a a a a a] [:B b b b]] [:AB [:A a a a a] [:B b b]]] https://github.com/Engelberg/instaparse for full feature list and extensive tutorial. -- -- 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.
Accessing Java members, from Clojure
Hi all, I have a polyglot project, comprising of a little Java and mostly Clojure code. The Java class is a concrete callback for an external library. There will be sub-second firing of that callback, and event map objects will get pushed onto a list. From Clojure, I need to access that list in the callback. The problem is that, in Clojure, we have STM (like refs) that can control access to the data. If that data member is in Java, how can I control the access? From Clojure, I could potentially access and flush the list, while the Java callback is writing to it. Is there a better strategy here? Can Java access a STM ref in Clojure? How might that work? Thanks Tim -- -- 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.
Disable undocumented #= reader macro to prevent unsafe code injection?
Hello -- I would like to use Clojure to build a safe code-remoting application for query injection (moving queries closer to the data for affinity and privacy). One alternative for this application is to read Clojure code from strings WITHOUT evaluating it, then analyze the presented code and / or eval it with a custom eval function in a sandbox. It's easier to do this in Clojure than in JavaScript because it's easier to write a custom eval in Clojure than in JavaScript. One problem with my plan is that the #= reader macro evaluates the code at read-time, before I have a chance to analyze or sandbox it. The workarounds seem to be disabling or removing the #= reader macro or writing my own custom reader (in addition to a custom evaluator). I'd be grateful for guidance and advice. -- -- 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: Disable undocumented #= reader macro to prevent unsafe code injection?
On Tue, Apr 9, 2013 at 6:03 PM, rebcabin bc.beck...@gmail.com wrote: Hello -- I would like to use Clojure to build a safe code-remoting application for query injection (moving queries closer to the data for affinity and privacy). One alternative for this application is to read Clojure code from strings WITHOUT evaluating it, then analyze the presented code and / or eval it with a custom eval function in a sandbox. It's easier to do this in Clojure than in JavaScript because it's easier to write a custom eval in Clojure than in JavaScript. One problem with my plan is that the #= reader macro evaluates the code at read-time, before I have a chance to analyze or sandbox it. The workarounds seem to be disabling or removing the #= reader macro or writing my own custom reader (in addition to a custom evaluator). I'd be grateful for guidance and advice. #= was an issue that was addressed in Clojure 1.5. (Though you should use 1.5.1 which fixes a memory leak). The read and read-string [1] functions have always been controllable by setting *read-eval* [2] to nil or false to disable the eval-reader. However, in Clojure 1.4 and below, this still allowed execution of record and class constructors, which probably isn't desired. In Clojure 1.5.1 setting *read-eval* to nil or false should (I think) disable all eval-on-read facilities. (Though I'd get a second opinion on that before relying on it) Clojure 1.5.1 also brought the new clojure.edn [3] namespace, which provide safe reading of clojure data structures as data, but doesn't support all of the features of the reader that might be used in code. For your usage, it sounds like this might be unsuitable. [1] http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/read-string [2] http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/*read-eval* [3] http://clojure.github.io/clojure/clojure.edn-api.html -- -- 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: Disable undocumented #= reader macro to prevent unsafe code injection?
Also - take a look at: https://github.com/flatland/clojail -- Dave -- -- 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: Disable undocumented #= reader macro to prevent unsafe code injection?
On Tue, Apr 9, 2013 at 10:03 AM, rebcabin bc.beck...@gmail.com wrote: The workarounds seem to be disabling or removing the #= reader macro or writing my own custom reader (in addition to a custom evaluator). Disabling #= by binding *read-eval* to false would cause an exception if such an expression ever occurred within the code, yes. I don't know off hand exactly which functionality this would cut out from the application you are considering, but probably at least some, if not a crucial part of what you want. Note that even when binding *read-eval* to false, there is no promise that clojure.core/read or read-string won't have other side effects. They *might* happen to be free of side effects in Clojure 1.5.1, but you'd need to do your own code review, testing, etc. if it matters to you. In Clojure 1.3 and 1.4, even binding *read-eval* to false allows some side effects during reading. Examples of this are given at http://clojuredocs.org/clojure_core/clojure.core/read I would recommend asking the authors of clojail or other sandbox environments whether you can call clojure.core/read or read-string from *within* the sandbox, and have the sandbox's restrictions apply to any #= expressions encountered during the reading. Again, not sure if that would achieve your goals, but if it does, it sounds quicker than writing your own custom reader. If you do end up writing your own custom reader, and you prefer developing in Clojure rather than Java, and the Eclipse Public License doesn't present any problems for you, consider starting with the tools.reader contrib library: https://github.com/clojure/tools.reader 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: [ANN] Instaparse 1.0.0
Wow, the enthusiastic response has been really gratifying. Thanks for the kind words; I hope as people try it out that it lives up to the hype. On Tue, Apr 9, 2013 at 4:47 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Do you have a roadmap for the next releases ? Initially, my focus will be on gathering feedback from users: making sure it's as stable as I think it is, gathering feature requests. Beyond that, my next objective is to produce a version that can leverage multiple threads. I'm not sure whether the parser really needs to be any faster than it currently is, but Clojure makes it so easy, I might as well offer that. Of interest to me: - restartable version ? (probably doable, if internal implementation uses immutable datastructures) - incremental version ? (Dunno if that's an easy one, and way beyond my current programming skills anyway to be able to even judge) I don't know offhand how doable these are either. I'd need to investigate further. It wasn't really a goal of mine, since Parsley already addresses that space. - possibility to have transform-map(s) passed as an argument to parse, so that a collection of views can be applied in parallel and the tree be traversed once ? Actually, I've already done something very similar to this. You can find it in the transform branch of the github page, and you're welcome to try it out and let me know what you think. The tutorial has been updated on that branch to explain how to use that feature, but it basically works the way you'd expect -- you simply pass the transform map as an argument to *parser* (the parser-building function, not the parse function) using the keyword :transform. When you do this, the transforms are done during parse time so the tree is traversed only once. The tradeoff is that parsers with baked-in transforms can't be serialized with print-dup. I like the feature, but hesitated to include it. I timed parsers with baked-in transforms against those where the transforms were applied after the fact. On the examples I tried, the time difference was minuscule, presumably because the version with the baked-in transforms ends up applying the transforms to various partial parses along the way. Some of these partial parses are eventually discarded, so applying transforms to those unsuccessful parses means you're doing extra work that potentially cancels out much of the savings from not having to traverse the tree a second time. What this means is that if I include this feature, I have to make sure users clearly understand that it is a tradeoff (possibly better performance, possibly not, depending on context; affects serialization). I like the idea of adding that level of control as to whether the transform is done at parse time or afterwards but, based on my limited experimentation, the benefits didn't seem to outweigh the degree to which it adds to the learning curve. I decided, for now, to make it available as a branch for people to play around with it, and see if it offers any compelling advantages that tip the balance in favor of including it. Your suggestion to make it a keyword argument to the parse function is also possible; I mainly included it in the parser-building function because then the attachment of the transform functions to the parser only needs to be done once, giving it a (tiny) performance boost versus doing it every time in the parse function. Have you tried some tests to compare performance with e.g. same grammars in Antlr ? No, I haven't done back-to-back performance tests. I'm guessing that Antlr would be hard to compete with. Before I began work, I played around with other Clojure parsers to get a feel for their performance, and I believe instaparse to be competitive with those. That statement is based more on feel than precise benchmarks, though. I focused my performance tuning on improving instaparse relative to itself, trying to get parse time to scale linearly with the size of the input, for as many grammars as possible. -- -- 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] Instaparse 1.0.0
On Tue, Apr 9, 2013 at 7:14 AM, Tassilo Horn t...@gnu.org wrote: IMHO, it would be cool if a clojure parser library would use a similar format (exploiting clojure data structures beyond lists where they make sense), at least internally. Of course, one could still have other frontends like for the EBNF you are using which would be translated to the internal format. There already are several clojure parser libraries that rely more heavily on Clojure data structure syntax to define grammars; in fact, that's probably the norm. Instaparse was definitely intended as an alternative to that approach. That said, instaparse definitely uses Clojure data structures internally to represent the parser and provides constructor functions to build them. It would be pretty easy to build other front-ends that translate to its internal format, including one that tries to strike a balance between readability and homoiconicity. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessing Java members, from Clojure
On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington twash...@gmail.comwrote:
Hi all,
I have a polyglot project, comprising of a little Java and mostly Clojure
code. The Java class is a concrete callback for an external library. There
will be sub-second firing of that callback, and event map objects will get
pushed onto a list.
From Clojure, I need to access that list in the callback. The problem is
that, in Clojure, we have STM (like refs) that can control access to the
data. If that data member is in Java, how can I control the access? From
Clojure, I could potentially access and flush the list, while the Java
callback is writing to it.
Is there a better strategy here? Can Java access a STM ref in Clojure? How
might that work?
If you control the Java code, you may be able to use Clojure's STM from
inside it. You would wrap the state in a ref and call methods on the ref
object from Java. You'd also want to set up a transaction by calling
clojure.lang.LockingTransaction.runInTransaction (func), where func
implements IFn and the zero-argument invoke method is implemented to do the
transaction.
Alternatively, and maybe simpler, the Java callback could just .invoke a
function you've defined in Clojure and whose Var you've previously (during
initialization) accessed on the Java side to get at the function object and
store a reference to it into a static variable. The bulk of the callback
can then be handled inside of the Clojure function, in Clojure code, where
you can just write (dosync (alter foo ... ))
You might consider going still further and using gen-class, proxy, reify,
or deftype to generate the Java class, with method bodies written in
Clojure. You can use proxy, reify, or deftype to implement Java interfaces,
but you'd need gen-class if you needed to extend a concrete class defined
by the external library. Proxy is commonly used to implement Swing
listeners in Clojure code that I've seen, which sounds like a very similar
situation to yours. (User pushes a button, ActionListener is invoked and
uses a transaction to update the model.)
Finally, though it's trickier to do it right, you could give up Clojure's
concurrency constructs and rely on Java's. Have the callback synchronize on
a Java object with the state in it (synchronized (theObject) {
theObject.mutatingMethod(args); }), and use (locking the-object
(.mutatingMethod the-object args)) when you want to mutate it from Clojure,
and (locking the-object (do-something-with (.getFoo the-object))) when you
want to read it without it possibly being mutated at the same time by
another thread.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessing Java members, from Clojure
I'm not really sure I understand what you want to do here. If you want to access a Java class from Clojure, you can access it directly with the dot notation. If you are concerned about concurrency between your Java code and your Clojure code, this is no different from any concurrency in Java : you have to correctly publish your object from Java and make sure there are never two threads that try to write that variable at once. Accessing Clojure from Java is generally much more painful than the other way around, except when you prepare for it on the Clojure side (genclass et al). From what you're saying, I would advise you to take a look at java.util.concurrent.atomic.AtomicReference, which is sort of an atom in Java world. Then, from Clojure, if you have access to that reference, convert its content to a persistent data structure and manage it from Clojure from then on. Other than that, Clojure's Atoms are actually implemented in Java, so they should be usable, though not especially pleasant, since that was not their main purpose : https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Atom.java In particular, if you restrict yourself to the reset and compareAndSwap methods, you should be able to use a single atom to communicate effectively between Java and Clojure. Since I'm still not sure I understand your question, feel free to explain your problem further should I have missed the mark. On 9 April 2013 18:41, Timothy Washington twash...@gmail.com wrote: Hi all, I have a polyglot project, comprising of a little Java and mostly Clojure code. The Java class is a concrete callback for an external library. There will be sub-second firing of that callback, and event map objects will get pushed onto a list. From Clojure, I need to access that list in the callback. The problem is that, in Clojure, we have STM (like refs) that can control access to the data. If that data member is in Java, how can I control the access? From Clojure, I could potentially access and flush the list, while the Java callback is writing to it. Is there a better strategy here? Can Java access a STM ref in Clojure? How might that work? Thanks Tim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessing Java members, from Clojure
On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington twash...@gmail.comwrote: Hi all, I have a polyglot project, comprising of a little Java and mostly Clojure code. The Java class is a concrete callback for an external library. There will be sub-second firing of that callback, and event map objects will get pushed onto a list. Now, after the generic advice for sharing state between Java and Clojure, in your specific case it sounds like you might have only a single piece of state and it *may* be a queue being produced by the Java callback and consumed by Clojure. In the single-piece-of-state-but-not-a-queue case you could use java.util.concurrent.AtomicReference around a java.util.List from the Java side, or even a Clojure atom (clojure.lang.Atom class). In the queue case you can do better: java.util.concurrent.LinkedBlockingQueue. In the callback class, static LinkedBlockingQueue queue = new LinkedBlockingQueue(); and, in the callback method, queue.offer(anotherEventMapObject); in the Clojure code, (.poll CallbackClass/queue) to fetch an event map in the consumer (it will block, as the name implies, if the queue is empty until the producer offers another one, so you might want a dedicated thread to do the consuming, depending). -- -- 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.
New CSS library - Garden
Nobel Clojurians,
I am pleased to announce the alpha version of
*Garden*https://github.com/noprompt/garden,
a new library for writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being
too simple or too complex.
Currently the list of notable features include:
- Nestable rules
- Nestable declarations (this my change)
- A builtin set of tools for working with CSS unit values
- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
- Output formatting options
What's planned for the near future:
- The ability to use Clojure meta as a media query
- A builtin set of tools for working with CSS color values
- selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a
look at the *project's repository* https://github.com/noprompt/garden.
There is still quite a bit of ground to do cover and any
help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or send
pull requests. I would love nothing more than to see this library succeed
where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
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] java.jdbc 0.3.0-alpha1
Hi Sean Matching Socks,
first off, I like the new API design. Here are my questions and
suggestions:
1.) Despite the asymmetry I'm also thinking that passing entities
and identifiers functions via the db argument is quite
convienient. Otherwise I always have to wrestle with those extra
parameters and pass them through my underlying SQL generation
functions. Which I have to to with the db anyway (maybe one level
less).
2.) The default naming strategy for columns coming from the
database is at the moment lower-case. Wouldn't it be more
idiomatic to lower case and replace _ with -. That would be
more consistent with the Clojure defaults of naming keywords at
the expense of maybe performance. I use this naming strategy for
example, because I don't want to constantly remember which keys
in my maps use the Clojure and which the database convention.
Would this be an option for 0.3.0?
3.) Would it make sense to define some connection spec, into
which the current specs get translated to? Something like the
Ring SPEC for connections. I'm often interested in the name of
the database, the credentials of the hostname the database is
running on, etc. Something like this?
{:product :postgresql
:server-name example.com
:server-port 5432
:username tiger
:password scotch
:db my_db
}
Othwerwise thanks for your work on clojure.java.jdbc,
Roman.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessing Java members, from Clojure
Hey thanks for all the feedback. So I got a working solution, bits and pieces of this solution online. Cedric mentioned it, but basically, I'm having my java code call a clojure function that (via STM), pushes new event objects to a list in Clojure (fig.1). And with my Clojure code in place, my Java code looks like the below (fig.2). And this ensures that the Java callback pushes to an STM guarded place in memory. (def event-list (ref ())) (defn pushEvent [event] (dosync (alter event-list conj event) )) (defn -pushEvent [event] (pushEvent event)) fig.1 eventObject = ... ; //Load the namespace RT.var(clojure.core,eval).invoke(RT.var(clojure.core,read-string).invoke((use 'my.namespace))); //Find a function in namespace IFn fn = (IFn)RT.var(my.namespace,my-function); //Call that function Object result = *fn.invoke( eventObject );* System.out.println(result); fig.2 Now, this works, but I'm always open to a better idea. In clojure-land, 1) there's a thread constantly checking for new events on the list and 2) there will be a thread of execution for each eventID. So I'm trying to come up with the best data and functional pattern to handle all this. I'm not sure a plain-jane Clojure list does the trick. Hmm Tim No 6: I'm not a number. I'M A FREE MAN!!! No 2: HA HA HA HA HAAA -- The Prisoner On Tue, Apr 9, 2013 at 3:48 PM, Cedric Greevey cgree...@gmail.com wrote: On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington twash...@gmail.comwrote: Hi all, I have a polyglot project, comprising of a little Java and mostly Clojure code. The Java class is a concrete callback for an external library. There will be sub-second firing of that callback, and event map objects will get pushed onto a list. Now, after the generic advice for sharing state between Java and Clojure, in your specific case it sounds like you might have only a single piece of state and it *may* be a queue being produced by the Java callback and consumed by Clojure. In the single-piece-of-state-but-not-a-queue case you could use java.util.concurrent.AtomicReference around a java.util.List from the Java side, or even a Clojure atom (clojure.lang.Atom class). In the queue case you can do better: java.util.concurrent.LinkedBlockingQueue. In the callback class, static LinkedBlockingQueue queue = new LinkedBlockingQueue(); and, in the callback method, queue.offer(anotherEventMapObject); in the Clojure code, (.poll CallbackClass/queue) to fetch an event map in the consumer (it will block, as the name implies, if the queue is empty until the producer offers another one, so you might want a dedicated thread to do the consuming, depending). -- -- 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.
Does the try special form complect the catch and finally clauses?
I've been thinking about exceptions a bit and it occurred to me that the catch and finally clauses are orthogonal. I mean code in a catch clause runs conditional on a exception being thrown and code in a finally clause runs unconditional on whether there was an exception or not. So i think using try only through something like the following macros would make the intend of ones code more explicit. (defmacro simple-catch [maythrow clauses] `(try ~maythrow ~@(map #(cons 'catch %) clauses))) (defmacro simple-finally [maythrow body] `(try ~maythrow (finally ~@body))) -- -- 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: [GSoC 2013] CinC
Actually, I would be interested in doing this if still available :) On Mon, Mar 4, 2013 at 6:53 PM, Aaron Cohen aa...@assonance.org wrote: On Mon, Mar 4, 2013 at 11:26 AM, abp abp...@gmail.com wrote: Is this work related? http://clojurewest.org/sessions#martin https://github.com/kanaka/clojurescript Nope, completely unrelated, though similar work. --Aaron -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] java.jdbc 0.3.0-alpha1
On Tue, Apr 9, 2013 at 1:49 PM, r0man roman.sche...@burningswell.com wrote:
first off, I like the new API design.
Thanx.
1.) Despite the asymmetry I'm also thinking that passing entities
and identifiers functions via the db argument is quite
convienient. Otherwise I always have to wrestle with those extra
parameters and pass them through my underlying SQL generation
functions. Which I have to to with the db anyway (maybe one level
less).
Could you elaborate on your use case, in the context of the new API?
I'm trying to imagine what my underlying SQL generation functions
look like and how they relate to / have access to the db-spec.
The identifiers and entities macros allow you to wrap a block of code
containing the new API and/or the DSL and have the functions injected
automatically:
(entities (quoted \')
...
(insert! my-db :foo {:name Bar :level 123})
...
(identifiers as-is
...
(query my-db (select :name :foo (where {:level 123})
That is equivalent to the (much longer):
...
(insert! my-db :foo {:name Bar :level 123} :entities (quoted \'))
...
(query my-db (select :name :foo (where {:level 123} :entities
(quoted \')) :entities (quoted \')) :identifiers as-is)
;; assuming I got my parens right!
Given that SQL generation happens _before_ the db-spec is even
referenced - and happens in a separately evaluated form - I'm not
seeing how having :entities inside the db-spec helps here.
2.) The default naming strategy for columns coming from the
database is at the moment lower-case. Wouldn't it be more
idiomatic to lower case and replace _ with -.
Yes, but I didn't want to break backward compatibility (with the
default behavior of 0.2.x and earlier) since I expect people to
migrate easily and that seems like a gratuitous change, because it
would ripple thru all of the library's client code. I'm certainly
happy to provide a convenience function in the DSL, along with as-is,
lower-case, and (quoted x) to provide lower-case-and-hyphens in the
entity to Clojure direction (i.e., an identifiers function) and an
as-is-with-underscore in the opposite direction... with better
names... suggestions?
I believe the defaults in java.jdbc have always been (effectively):
* :identifiers lower-case
* :entities as-is
I don't want to make migration from 0.2.x to 0.3.0 difficult for folks
with large code bases (like me, for example!).
3.) Would it make sense to define some connection spec, into
which the current specs get translated to? Something like the
Ring SPEC for connections. I'm often interested in the name of
the database, the credentials of the hostname the database is
running on, etc. Something like this?
An interesting idea...
As it stands, the API functions all accept anything that
get-connection can turn into a database connection, and from a
connection you can get the catalog and quite a bit of metadata (via
.getCatalog and .getMetaData method calls). Some of the things you can
pass to get-connection don't directly contain the information you're
looking for (e.g., pass in a JNDI name / environment or a DataSource
object with username / password - not to be confused with the
user/password property used in some of the other connectable
things).
Feel free to add notes or comments here:
http://dev.clojure.org/display/design/java.jdbc
Also request enhancements here:
http://dev.clojure.org/jira/browse/JDBC (although some discussion
about things would be welcome first)
I have created a mailing list specific to clojure.java.jdbc in case
folks want to get into deep discussions and don't want to clog up this
main Clojure mailing list (since I understand the user base for
java.jdbc is relatively small compared to the overall Clojure
community): https://groups.google.com/d/forum/clojure-java-jdbc
--
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: Accessing Java members, from Clojure
On Tue, Apr 9, 2013 at 5:00 PM, Timothy Washington twash...@gmail.comwrote: Now, this works, but I'm always open to a better idea. In clojure-land, 1) there's a thread constantly checking for new events on the list and 2) there will be a thread of execution for each eventID. So I'm trying to come up with the best data and functional pattern to handle all this. I'm not sure a plain-jane Clojure list does the trick. If you're polling for new events on the list, then you might want to use LinkedBlockingQueue. Or perhaps an agent: (def event-agent (agent initial-agt-contents)) (defn -pushEvent [event] (send event-agent event-handler event)) (defn event-handler [agt-contents event] ...) The event handler can keep track of any stateful stuff in agt-contents; whatever it returns will be agt-contents the next time it's invoked. For example (def event-agent (agent 0) (defn -pushEvent [event] (send event-agent event-handler event)) (defn event-handler [event-count event] (logger/log! (extract-log-details-from-event event)) (inc event-count)) will result in @event-agent evaluating to the number of events handled thus far, increasing over time, while some logger is triggered to log each event as it arrives. -- -- 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.
Confluence (http://dev.clojure.org) maintenance tonight
We're going to bring Confluence down for maintenance. This will start at 9pm Eastern. I anticipate it should only be down for less than 30 minutes. -- -- 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: IMPORTANT: For Potential GSoC 2012 mentors, do this now please!
I'm also stuck on this. I see the My Dashboard link, but no list of projects. does someone need to accept me as a mentor first perhaps? On Tuesday, 10 April 2012 00:54:46 UTC+8, David Nolen wrote: You don't see a My Dashboard link? On Mon, Apr 9, 2012 at 12:52 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: On Mon, Apr 9, 2012 at 7:17 AM, David Nolen dnolen...@gmail.comjavascript: wrote: Yes apply to be a mentor - sorry it wasn't more clear - this could have been done at anytime. Also important DO NOT associate yourself with a proposal in Confluence - you MUST do this in Melange. Feeling a bit slow... I don't see any proposals listed for Clojure in Melange even though I've been accepted as a mentor: http://www.google-melange.com/gsoc/org/google/gsoc2012/clojure How does one associate themselves with a proposal? -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: IMPORTANT: For Potential GSoC 2012 mentors, do this now please!
Hello, Mike, On Tue Apr 9 17:31 2013, Mikera wrote: I'm also stuck on this. I see the My Dashboard link, but no list of projects. does someone need to accept me as a mentor first perhaps? I got your mentorship application and you should be approved now as a mentor. I plan on writing some more detailed instructions for students and mentors in the next few days. I haven't yet had the chance to look around and figure out the Melange app. Sincerely, Daniel On Tuesday, 10 April 2012 00:54:46 UTC+8, David Nolen wrote: You don't see a My Dashboard link? On Mon, Apr 9, 2012 at 12:52 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: On Mon, Apr 9, 2012 at 7:17 AM, David Nolen dnolen...@gmail.comjavascript: wrote: Yes apply to be a mentor - sorry it wasn't more clear - this could have been done at anytime. Also important DO NOT associate yourself with a proposal in Confluence - you MUST do this in Melange. Feeling a bit slow... I don't see any proposals listed for Clojure in Melange even though I've been accepted as a mentor: http://www.google-melange.com/gsoc/org/google/gsoc2012/clojure How does one associate themselves with a proposal? -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. signature.asc Description: Digital signature
Re: [GSoC 2013] CinC
Hello, On Wed Apr 10 00:04 2013, Bronsa wrote: Actually, I would be interested in doing this if still available :) Well, now that we have been accepted as a mentoring organization, now is the time to start getting in touch with potential mentors and develop a proposal. The student application period won't open until April 22, but there is no reason to wait until then. Sincerely, Daniel On Mon, Mar 4, 2013 at 6:53 PM, Aaron Cohen aa...@assonance.org wrote: On Mon, Mar 4, 2013 at 11:26 AM, abp abp...@gmail.com wrote: Is this work related? http://clojurewest.org/sessions#martin https://github.com/kanaka/clojurescript Nope, completely unrelated, though similar work. --Aaron -- -- 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. signature.asc Description: Digital signature
Re: Confluence (http://dev.clojure.org) maintenance tonight
This maintenance has finished. On Tue, Apr 9, 2013 at 7:49 PM, Christopher Redinger redin...@gmail.comwrote: We're going to bring Confluence down for maintenance. This will start at 9pm Eastern. I anticipate it should only be down for less than 30 minutes. -- You received this message because you are subscribed to the Google Groups Clojure Dev group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscr...@googlegroups.com. To post to this group, send email to clojure-...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-dev?hl=en. 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.
[gsoc2013]ClojureScript Optimization
Hi, all, I'm very interested in optimizing clojurescript as I'm using it myself as frontend script language.I tried to get contact with David Nolen for this idea but couldn't find his email or github account. regards wliao lwlw1...@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 --- 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.
