Re: resultset-seq
I don't think it's flexible enough to attach this to the connection. I
work with databases where some groups of tables really need different
naming strategies than others so I would definitely want these
conversions available per operation - which is how c.j.j naming
strategies currently work so it would be easy enough for folks to
build something like Phlex suggests on top of what's already in c.j.j.
So it sounds like it would be useful to expose c.j.j's internal
resultset-seq* function?
And given it's default behavior matches the core version, exposing it
with the same name seems reasonable too since it won't break anyone's
code (right?).
Sean
On Wed, May 4, 2011 at 4:06 PM, Phlex wrote:
>
>
> On 3/05/2011 23:58, Allen Johnson wrote:
>>
>> IMHO c.j.j/resultset-seq should perform something like the following:
>>
>> ;; i want my columns as strings exactly how they are in the db
>> (resultset-seq rs)
>> (resultset-seq rs identity)
>>
>> ;; i want my columns as lower-case keywords
>> (resultset-seq rs (comp keyword lower-case))
>>
>> ;; i want my columns as upper-case symbols
>> (resultset-seq rs (comp symbol upper-case))
>>
>> With the existing c.c/resultset-seq, I found myself converting the
>> keys back to strings in order to pass those results to some existing
>> Java code and templates for further processing. Most of the time the
>> lower-cased keyword keys were just fine.
>>
>> Just my $0.02
>> Allen
>>
> It would definitely be a plus to have some facilities for conversion from/to
> clojure coding standard.
> Not only for result sets but also for update functions and so on.
>
> I personally would prefer this as a default :
> customer_id -> :customer-id (and the reverse)
>
> In a perfect world, it indeed would be best to have some control over this.
> Maybe add this context as parameters to the connection object ?
>
> (with-connection {:classname "org.postgresql.driver"
> :subprotocol "postgresql"
> :subname (str "//" db-host ":" db-port "/" db-name)
> :user user
> :password password
> :field-names {:from-sql pascal-case->clojure ; or something like
> this : (field-name-converter-fn :underscores :clojure-keyword)
> :to-sql clojure->pascal-case}}
> (do-stuff))
>
> field-name-converter-fn being a multi-method returning a lambda that does
> the conversion. One would be able to add his own methods, or simply use the
> identity function.
>
> Sacha
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On Wed, May 4, 2011 at 8:16 PM, Ken Wesson wrote: > Closures, including ones whose arguments can't be known until runtime, > can easily be slapped with "implements Serializable" if they haven't > been already. Indeed, an "extends Serializable" on IFn, on top of the > above compiler modification to externalize anything serializable, > would suffice to make it possible to eval (and even AOT-compile) code > containing any embedded function objects, save for closures that have > closed over non-serializable objects. One more clarification: *any* object could be eval'd. It would just be the case that if you tried to AOT compile code that contained (say, in the output of a macro expansion) a non-serializable, non-print-dupable object or a closure that had closed over one, the AOT compile would fail with a NotSerializableException (and the compiler could catch that and give a more helpful error message pointing to the offending line of Clojure code, so you could track down what object was making the AOT compile fail and fix it, either by replacing the literal object with code to recreate it or by adding a method to print-dup or slapping a Serializable on one of your Java classes or deftypes or whatever). As for concerns that this kind of extension might mask common macro errors, adding some *warn-on-foo* option to generate warnings when "unusual" kinds of object literal were encountered by eval/the compiler would hopefully address such. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On Wed, May 4, 2011 at 8:01 PM, Ken Wesson wrote:
> Note that instantiating the class with 4 gives us an add-4-to function
> instead of the original add-3-to function here. To actually convert
> that particular closure into code that reproduces it, the array of
> constructor arguments needs to be [{} 3]. (I'm not sure what the map
> argument is used for, but it seems to work when left empty, though not
> when omitted entirely. The compiler can always give closure objects
> metadata amounting to the correct [{} 3] or whatever needed to
> recreate the closure object by calling its class's constructor.
Actually, this would require the arguments to be known at compile
time. For (let [x 3] (fn [y] (+ x y))) this is possible, but for a
return value from
(defn adder-maker [n]
(fn [y] (+ n y)))
it's not.
But what are we really doing here? There are just two situations where
the compiler is being called. One is on-the-fly eval at runtime, and
then the bytecode could just be built with code that works something
along these lines:
makeJavaClassWithNullPublicStaticFieldItUses();
TheNewClass.THE_PUBLIC_STATIC_FIELD = someValue;
Here "someValue" would be an actual reference to the existing object
in memory, and it will work with closures and any other object, even
things like io streams backed by open file handles.
The second is for AOT compilation of Clojure code. In that case, what
we should probably aim for is that a) anything for which print-dup has
a method and b) anything that implements Serializable can be
externalized. For print-dupables you just print-dup to a string and
generate a class whose static initializer puts that back in through
the reader: something like
static {
someVar = RT.readString("(sorted-map [1 2 3 4])");
}
The proof of concept for Serializables is similar:
static {
someVar = (new ObjectInputStream
(new ByteArrayInputStream
(new byte[] {0x1b, 0xff, 0x3a, 0xa7, ...}))).readObject();
}
where the contents of the byte array literal are generated using
ObjectOutputStream/ByteArrayOutputStream, natch.
Closures, including ones whose arguments can't be known until runtime,
can easily be slapped with "implements Serializable" if they haven't
been already. Indeed, an "extends Serializable" on IFn, on top of the
above compiler modification to externalize anything serializable,
would suffice to make it possible to eval (and even AOT-compile) code
containing any embedded function objects, save for closures that have
closed over non-serializable objects.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On Wed, May 4, 2011 at 7:03 PM, Simon Katz wrote:
> It is not possible to write out a function object (something returned
> by lambda, Common Lisp's equivalent of fn) to a compiled file. No mix
> of eval-when, separating functions and macros, and load order can
> change that.
The same is not true of Clojure functions, though. Any function object
reference can be turned in bytecode into a constructor call to the
appropriate class -- with a closure, passing the appropriate argument.
For example:
user=> (class map)
clojure.core$map
user=> (.newInstance (class map))
#
user=> (.invoke (.newInstance (class map)) inc [1 2 3 4 5])
(2 3 4 5 6)
So, to embed map (not 'map or 'clojure.core/map, but map itself) in
(eval `(~map inc [1 2 3 4 5])) you could generate the bytecode for
this Java:
(new clojure.core$map()).invoke(reference-to-inc-function,
reference-to-1-2-3-4-5-vector);
With a closure, it's slightly more complicated:
user=> (def q (class (let [x 3] (fn [y] (+ x y)
#'user/q
user=> q
user$fn__1501$fn__1502
user=> (.invoke (.newInstance (first (.getConstructors q)) (to-array
[{} 4])) 42)
46
Note that instantiating the class with 4 gives us an add-4-to function
instead of the original add-3-to function here. To actually convert
that particular closure into code that reproduces it, the array of
constructor arguments needs to be [{} 3]. (I'm not sure what the map
argument is used for, but it seems to work when left empty, though not
when omitted entirely. The compiler can always give closure objects
metadata amounting to the correct [{} 3] or whatever needed to
recreate the closure object by calling its class's constructor.
The original problem *can* reappear with one step of regress *if* the
constructor arguments include something the compiler doesn't knows how
to turn into bytecode -- i.e. (eval (atom {})) still won't work, and
so neither will (eval (let [x (atom {})] (fn [y] (reset! x y, but
(eval (let [x 3] (fn [y] (+ x y should work at that point as 3 is
something that can already be turned into bytecode.
Of course, for these trivial examples it's easy enough to turn the
function or closure into a quoted expression that constructs it, such
as (eval '(let [x 3] (fn [y] (+ x y. Where we run into problems is
when we want to embed references to already-existing functions or
other objects that lack global names. (There's an ugly workaround
involving explicitly calling intern; you create a dummy namespace with
a var holding the object, and then eval code that refers to that var
by fully-qualified name in order to retrieve the object.)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: resultset-seq
On 3/05/2011 23:58, Allen Johnson wrote:
IMHO c.j.j/resultset-seq should perform something like the following:
;; i want my columns as strings exactly how they are in the db
(resultset-seq rs)
(resultset-seq rs identity)
;; i want my columns as lower-case keywords
(resultset-seq rs (comp keyword lower-case))
;; i want my columns as upper-case symbols
(resultset-seq rs (comp symbol upper-case))
With the existing c.c/resultset-seq, I found myself converting the
keys back to strings in order to pass those results to some existing
Java code and templates for further processing. Most of the time the
lower-cased keyword keys were just fine.
Just my $0.02
Allen
It would definitely be a plus to have some facilities for conversion
from/to clojure coding standard.
Not only for result sets but also for update functions and so on.
I personally would prefer this as a default :
customer_id -> :customer-id (and the reverse)
In a perfect world, it indeed would be best to have some control over
this. Maybe add this context as parameters to the connection object ?
(with-connection {:classname "org.postgresql.driver"
:subprotocol "postgresql"
:subname (str "//" db-host ":" db-port "/" db-name)
:user user
:password password
:field-names {:from-sql pascal-case->clojure ; or something
like this : (field-name-converter-fn :underscores :clojure-keyword)
:to-sql clojure->pascal-case}}
(do-stuff))
field-name-converter-fn being a multi-method returning a lambda that
does the conversion. One would be able to add his own methods, or simply
use the identity function.
Sacha
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On May 4, 11:31 pm, André Thieme wrote: > Am 04.05.2011 14:50, schrieb Simon Katz: > > >> For example Common Lisp does support this. > > > That's not true, or at least it's only partly true. > > > Here's a translation of your example into Common Lisp (I added a use > > of a# in the macro to avoid compiler optimization making the problem > > go away): > > > (defun f (x) (lambda () x)) > > (defparameter foo (f 0)) > > (defmacro bar () `(let ((a# ,foo)) a#)) > > (defun call-bar () (bar)) > > > I can compile this within a Lisp image (not compiling to file), and > > call call-bar with no problems. > > > But if I try to compile to file, compilation fails with the error > > Object # is of type FUNCTION which is not > > externalizable > > You need to wrap it into eval-when or separate functions and macros from > their use into different files and make sure the right load order is > used. Then this will work in CL. > > Andr It is not possible to write out a function object (something returned by lambda, Common Lisp's equivalent of fn) to a compiled file. No mix of eval-when, separating functions and macros, and load order can change that. Simon -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On Wed, May 4, 2011 at 6:31 PM, André Thieme wrote: > You need to wrap it into eval-when or separate functions and macros from > their use into different files and make sure the right load order is > used. Then this will work in CL. Which are probably some of the reasons Clojure chose not to support the behavior. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
Am 04.05.2011 14:50, schrieb Simon Katz: For example Common Lisp does support this. That's not true, or at least it's only partly true. Here's a translation of your example into Common Lisp (I added a use of a# in the macro to avoid compiler optimization making the problem go away): (defun f (x) (lambda () x)) (defparameter foo (f 0)) (defmacro bar () `(let ((a# ,foo)) a#)) (defun call-bar () (bar)) I can compile this within a Lisp image (not compiling to file), and call call-bar with no problems. But if I try to compile to file, compilation fails with the error Object # is of type FUNCTION which is not externalizable You need to wrap it into eval-when or separate functions and macros from their use into different files and make sure the right load order is used. Then this will work in CL. André -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)
On May 4, 2011, at 2:52 PM, Sean Corfield wrote: > On Wed, May 4, 2011 at 6:20 AM, Chas Emerick wrote: >> Any breadcrumb navigation would require mousing around a bit > > Unless it was entirely driven by keyboard shortcuts :) > >> Perhaps what might be useful is a quick way to show the graph of nodes >> you've visited in the current session -- breadcrumbs of a sort, but shown in >> the graph itself so you can easily peek back at docs and (once I implement >> it) inspect the connecting edges? > > Sounds like that would do what I'm after, yes. Between these two, I'm now noodling on making navigation entirely keyboard-driven. Thanks :-) > I'm a "paying customer" of the Atlas now, BTW. Looking forward to > completion of the content and the upcoming 1.3.0 version! Many thanks. The former is coming along nicely. There will likely be an update in that department this week. 1.3.0 will hopefully be available this month; I need to do a little refactoring so as to generalize the hosting of the atlases (seems like that should be atlai) -- everything is actually hardwired to 1.2.0 at the moment. :-/ - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
Alessio Stalla writes: > The key point is that in Lisp "code" does not mean "text" [1]. Code is > made of data structures - lists, symbols, vectors, numbers, ... - and > macros are just functions that operate on those data structures. Hmm, interesting. One of the things that's drawn me to learning Clojure is the malleability of "code as data," but I hadn't thought about it as potentially running that deep before. Thanks for phrasing that in a way that clicked for me. > In other words, valid code is no longer determined by the reader (i.e. > the parser), but by the compiler and/or the interpreter, that take a > rich data structure as input. The reader is "only" useful to us humans > to enter code into the system. OTOH, the compiler still needs a defined interface. The data structures the reader is able to produce seem like a convenient definition for what data structures the compiler should meaningfully consume. Obviously the reader producing structures the compiler can't consume is useless, but the compiler consuming structures the reader can't produce seems equally problematic to me. It seems like code which doesn't have a textual representation would be much more difficult to reason about. Without guaranteeing a mapping from every valid compiler input to text which causes the reader to directly generate that input, it becomes impossible to inspect what the compiler is actually consuming. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)
On Wed, May 4, 2011 at 6:20 AM, Chas Emerick wrote: > Any breadcrumb navigation would require mousing around a bit Unless it was entirely driven by keyboard shortcuts :) > Perhaps you're hoping for an 'up' that was equivalent to two 'back' actions…? Probably. Like I say, maybe I just need to work with it some more. > Perhaps what might be useful is a quick way to show the graph of nodes you've > visited in the current session -- breadcrumbs of a sort, but shown in the > graph itself so you can easily peek back at docs and (once I implement it) > inspect the connecting edges? Sounds like that would do what I'm after, yes. > Contributing to classic contrib was much more difficult than it is to > contribute to "new contrib" I'll have to take your word for that :) > I have to believe that the latter will be far larger in relatively short > order, while being of far higher quality at the same time. +1 on that second point. I'm a "paying customer" of the Atlas now, BTW. Looking forward to completion of the content and the upcoming 1.3.0 version! -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
Re: I am new comer for clojure, I concern that when will clojure surpport Distribution function like erLang
You can use the erlang-otp Java library from Clojure. I think there are bindings on github. If not, they are simple to generate. (I actually had clojure hooked up to a yaws webserver (yaws pattern matches requests, clojure generates pages) for a while, using LFE and the OTP libraries. Clojure writes LFE code describing server + connections to file, compiles it with LFE compiler to Erlang Bytecode, load server and start. I got distracted and it got abandoned. I'll dig out the code later and post it if I can find it) You could do a similar thing to connect Clojure to Clojure. On May 4, 2:27 am, yanzhao ye wrote: > I am new comer for clojure, I concern that when will clojure surpport > Distribution function like erLang > > yeah, the up is my question. > and I want to know is there any roadmap for clojure ? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On May 4, 8:50 am, Simon Katz wrote:
> > For example Common Lisp does support this.
>
> That's not true, or at least it's only partly true.
>
> Here's a translation of your example into Common Lisp (I added a use
> of a# in the macro to avoid compiler optimization making the problem
> go away):
>
> (defun f (x) (lambda () x))
> (defparameter foo (f 0))
> (defmacro bar () `(let ((a# ,foo)) a#))
> (defun call-bar () (bar))
>
> I can compile this within a Lisp image (not compiling to file), and
> call call-bar with no problems.
>
> But if I try to compile to file, compilation fails with the error
> Object # is of type FUNCTION which is not
> externalizable
>
> Common Lisp's notion of externalizable objects (when compiling) is
> defined athttp://www.lispworks.com/documentation/HyperSpec/Body/03_bda.htm.
>
> Regards,
> Simon
Yes.
And actually, it is sort of better to think about (lambda () x) { (fn
[] x), in clojure} as the name of a function. Even though it is also a
list, it is also the name of 'the function that returns x'.
When trying to insert the literal function generated by (lambda () x),
you generate an error, because you can't insert literal functions into
macros, they aren't symbolic... only their names are.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On May 3, 5:22 pm, André Thieme wrote: > Am 02.05.2011 23:14, schrieb David Nolen: > > > The relevant clojure-dev thread. > >http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907... > > > It's not clear whether the core team and the various contributors are > > interested in supporting the behavior you want. It's also not clear > > whether the issue is matter of the difficulty of a good implementation > > or simply disinterest. > > Thanks for that link. I would really like to hear (read) a statement of > one member of the core team. > Some of the limitations: > 1. (defmacro x [] `(let [a# ~(atom 0)])) > > 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link > > 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) > > All three calls fail, (x) and (y) and (z). > I see no plausible reason why it *should* be that way. > Instead this is useful and idiomatic lisp. > > Normally I wanted to write: > `(~(get @loggers level @logger) > ~(get *level-name* level) > ~domain ~msg ~e) > > The first get will see if for the given level there is a level > specific log function. If not it will fall back to the default logger > logger . So, loggers is a mapping from level to closures and > logger is a closure. Those closures are functions that take 4 args: > the log level, a domain, a message and an exception. > > Now I have to write instead > (let [l (get @loggers level @logger) > f (gensym "logger")] > (intern 'mylib.log f l) > `(~f ~(get *level-name* level) ~domain ~msg ~e)) > > which is plain ugly. I need to artificially invent a name, pollute the > NS of my logging lib and probably create less efficient code, because > a lookup of my gensymed ~f will be required at runtime. > Would be great if this could be fixed easily enough to get included in > a (near) future version. > > Regards, > Andre You can do this the original way you were trying to do if you change your closure factory into a 'closure-code-factory'. Essentially, instead of returning a (fn [x] ...), you want to return something that's been syntax-quoted (but of the same form). (You could make this pretty using a macro). Then you would insert this anonymous lambda wherever you need it, and call it inline (after binding with let or using apply). There needn't be any lookup and It shouldn't be any less efficient than what you are trying to do. Of course, you should note that the downside to this entire approach is that to change the logging settings, you have to recompile the entire program, which could get quite annoying. (Particularly if you wanted to turn logging on at a breakpoint or something). It might be better to take the hit on dereferencing, as it would be more useful, and then also include an option to eliminate all logging code by flipping a variable. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On 4 Mag, 16:29, "Marshall T. Vandegrift" wrote: > André Thieme writes: > > Please try this minimal example in your REPL: > > (defn f [x] (fn [] x)) ; the closure factory > > (def foo (f 0)) ; a useful instance > > (defmacro bar [] `(let [a# ~foo])) > > and then call (bar) > > I'm new to Clojure and don't have much experience with Lisps in general, > but trying to do this seems weird to me. My understanding is that > macros are, well, macros -- code which is expanded at compile-time to > other code. In which case the interface the macro facility provides > isn't a set of compiler hooks, but just the ability to factor and > abstract the same code you could write without the macro facility. What > ultimate code-expansion are you trying to achieve? Perhaps there's a > different way to do it which works within the confines of pure code > re-writing. The key point is that in Lisp "code" does not mean "text" [1]. Code is made of data structures - lists, symbols, vectors, numbers, ... - and macros are just functions that operate on those data structures. In other words, valid code is no longer determined by the reader (i.e. the parser), but by the compiler and/or the interpreter, that take a rich data structure as input. The reader is "only" useful to us humans to enter code into the system. Alessio [1] actually this is matter of debate, for example in the Common Lisp standard "code" is defined with both meanings, but without complicating things too much, my point is that the canonical form of the code - the one that is fed to the compiler - is not text. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Logos -> core.logic
On Wed, May 4, 2011 at 11:11 AM, David Nolen wrote: > On Wed, May 4, 2011 at 10:37 AM, Frantisek Sodomka wrote: > Mercury is an amazing project. In fact the original miniKanren (on which > core.logic is based) designers were well aware of it and even based their > soft-cut and committed choice notions on it. So there's some pieces of > Mercury already in core.logic ;) > > Mercury also makes a quite a few design decisions (many related to > performance) that take it far away from Prolog - it doesn't even have a > REPL. Still there's a goldmine of interesting papers related to that project > that I've only scratched the surface of - Mercury's STM, etc. > > David > While we're on the topic of logic programming languages, something I would really like to see get folded into core.logic would be a constraint solving library, something along the lines of Constraint Handling Rules (CHR) ( http://en.wikipedia.org/wiki/Constraint_Handling_Rules). A good introduction to the ideas behind CHR can be found in Concepts, Techniques, and Models of Computer Programming (an excellent text for the Clojurian on many fronts). David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure group in DFW area
Thanks everyone for attending the first meeting. It was great to talk clojure with some like minded people who are excited by the possibilities ! Our next meeting is scheduled for May 16th 630PM - 900PM @ Rubedo, inc. 14580 Beltwood Pkwy E Suite 103 Farmers Branch, TX 75244 (wifi available) Right now, we will try for two meetings each month. In the beginning, these will be mostly hack nights. As the group matures, we will look at doing presentations / talks on Clojure. As most of the group is relatively new to Clojure, we decided to start with the http://projecteuler.net/ problems as a way to get familiar with the language and have some common solutions to discuss. At our next meeting, we will bring our solutions for problems 1-10 and discuss how we went about solving them. All are welcome ! On Apr 25, 9:08 pm, Christopher Redinger wrote: > ch...@rubedoinc.com wrote: > > Rubedo, inc. > > 14580 Beltwood Pkwy E Suite 103 > > Farmers Branch, TX 75244 > > > When: 630PM Monday May 2nd > > What: Clojure Interest Group > > Topic: 1st meeting, what our goals are, and how to take over the world > > with Clojure > > Hi Chris! Thanks for offering to host the group. I've added a link to > this thread on the Clojure User Groups > page:http://dev.clojure.org/display/community/Clojure+User+Groups. > Hopefully to help people who might be looking. We can update the link > to something with a little more information if you get a page set up > somewhere. > > Also, if you choose to go through Meetup, they have provided us with a > code that gives a discount to Clojure groups. See the above page for > more information. > > Thanks again, and let me know if there's anything Clojure/core can > help you out with! > > Thanks, > Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[Enlive] Search for a node querying on attrs
Hi to everyone, due to the lack of documentation I'm struggling with the good Enlive library. I'm trying to get the meta keywords from a web page, to be clearer from this: I want to extract only the content part. I've tried with something like this: (defn get-keywords-from "Given the HTML URL of a web page, parses it and returns the keywords associated with the page." [page-src] (-> page-src java.net.URL. en/html-resource (en/let-select [[meta] [:meta]] (println meta But it retrieve only the first meta field it encounter (usually ) and I can't find a way to say "Hey Enlive, search for a node named "meta" with the property "name" that matches "keywords" and give me the content of the field "content". I hope to have been clear :) Bye and thanks, Alfredo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
> 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) > > All three calls fail, (x) and (y) and (z). > I see no plausible reason why it *should* be that way. As it's been pointed out, the compiler won't re-compile compiled code. Those macros work if you don't unquote the expressions: (defmacro x [] `(let [a# (atom 0)] a#)) (defmacro y [] `(let [a# (comp inc inc)] a#)) (defmacro z [] `(let [a# ((fn [x#] (fn [] x#)) 0)] a#)) user=> @(x) 0 user=> ((y) 1) 3 user=> ((z)) 0 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Logos -> core.logic
On Wed, May 4, 2011 at 10:37 AM, Frantisek Sodomka wrote: > Hello David, > thanks for your work. It is very interesting addition. > > One thing that came to my mind, is a language Mercury: > http://en.wikipedia.org/wiki/Mercury_(programming_language) > http://www.mercury.csse.unimelb.edu.au/ > > Mercury is an amazing project. In fact the original miniKanren (on which core.logic is based) designers were well aware of it and even based their soft-cut and committed choice notions on it. So there's some pieces of Mercury already in core.logic ;) Mercury also makes a quite a few design decisions (many related to performance) that take it far away from Prolog - it doesn't even have a REPL. Still there's a goldmine of interesting papers related to that project that I've only scratched the surface of - Mercury's STM, etc. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Logos -> core.logic
Hello David, thanks for your work. It is very interesting addition. One thing that came to my mind, is a language Mercury: http://en.wikipedia.org/wiki/Mercury_(programming_language) http://www.mercury.csse.unimelb.edu.au/ "Mercury is a new logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs." It is based on both Prolog and Haskell and claims to be very fast. Maybe you could check it out and see, what makes it different and maybe worthwhile studying. Some parts could be useful and shed some light on union of functional and logical universes :-) Lots of fun with logical programming wishes, Frantisek PS: Not meant as advertisement of Mercury. On Thu, Apr 28, 2011 at 9:19 PM, David Nolen wrote: > On Thu, Apr 28, 2011 at 3:05 PM, Nick Zbinden wrote: > >> Hallo David, >> >> Very cool that this is moving to contrib. >> >> I saw that you gave a presentation at NYC Clojure User Groupe. Was >> that tapped? If not I think it would be very cool if you could do a >> screencast with simular content. The videos of rich showing of clojure >> a reason why some of use are here (including me) and I think it would >> be great if we had something like this for your library (and logic >> programming spezially). >> > > Sadly it wasn't recorded, but it went over very well. > > >> >> Like you sad logic programming is not well known yet and its hard to >> tell people what it is spezially if your not an expert yourself. It >> would be great to just be able to send somebody a link of a video >> expmlaing a little bit about it (in clojure). >> >> Nick > > > Well I wouldn't consider myself an expert in any of these matters, but I'm > interested in making the library more accessible so tutorials and > screencasts are something I'm thinking about. > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
André Thieme writes: > Please try this minimal example in your REPL: > (defn f [x] (fn [] x)) ; the closure factory > (def foo (f 0)) ; a useful instance > (defmacro bar [] `(let [a# ~foo])) > and then call (bar) I'm new to Clojure and don't have much experience with Lisps in general, but trying to do this seems weird to me. My understanding is that macros are, well, macros -- code which is expanded at compile-time to other code. In which case the interface the macro facility provides isn't a set of compiler hooks, but just the ability to factor and abstract the same code you could write without the macro facility. What ultimate code-expansion are you trying to achieve? Perhaps there's a different way to do it which works within the confines of pure code re-writing. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
New contrib releases
Hello all, I just pushed out two new releases. * [org.clojure/tools.macro "0.1.0"] ** Includes all the bits from c.c.macro-utils and name-with-attributes from c.c.def. Thanks to Konrad who did the initial leg work for this * [org.clojure/core.incubator "0.1.0] ** Includes the bits from c.c.core and defmacro- from c.c.def They have been released to sonatype and should hit central within a couple of hours -- Cheers, Aaron Bedra -- Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Declarative Data Models
apply-macro is a bad idea because it evaluates a macro at runtime. Macros are supposed to be evaluated at compile-time, so apply-macro breaks assumptions about how macros are supposed to work. It's basically a back door into `eval`, which is considered bad style in Lisp-like languages. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: I am new comer for clojure, I concern that when will clojure surpport Distribution function like erLang
Clojure doesn't currently provide features for distributed computation across multiple machines. It focuses on the problem of concurrency within a single machine. However, there are many libraries for the JVM designed to support distributed computation. Message-queue systems like ActiveMQ and RabbitMQ work particularly well with Clojure, as do distributed coordination systems like ZooKeeper and Hazelcast. People have also explored using Clojure on distributed-JVM systems like Teracotta, although that may still require some modifications to Clojure - search the list archives for notes. Clojure doesn't have a formal roadmap beyond the next release, but future plans will likely involve writing more of the Clojure compiler in Clojure itself, to make it easier to enhance the compiler and port it to other platforms. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: I am new comer for clojure, I concern that when will clojure surpport Distribution function like erLang
On Wed, May 4, 2011 at 11:57 AM, yanzhao ye wrote: > I am new comer for clojure, I concern that when will clojure surpport > Distribution function like erLang > > yeah, the up is my question. > and I want to know is there any roadmap for clojure ? Take a look at Jobim for Erlang style distributed concurrent programming - https://github.com/antoniogarrote/jobim Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language & standard library)
On May 3, 2011, at 10:21 PM, Sean Corfield wrote: >> FWIW, click-and-hold on the back or forward buttons in your browser will >> give you the "breadcrumbs" you're looking for. > > Hmm... that means taking the mouse out of the atlas and interacting > with the chrome of its surroundings... Any breadcrumb navigation would require mousing around a bit -- whether that's up to the browser's buttons or up to a history in the toolbar. Note that I'm all for having better navigation options within Clojure Atlas. I just want to make sure that those options are obviously better than what all the browsers provide by default. >> I'd like to plumb at this up/down notion a bit. Perhaps it's not clear, but >> the ontology is not a hierarchy – there absolutely are cycles in its graph. >> For example: >> >> http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/isa? >> >> Which way is "up" (or "down") from isa? here? > > It was more relative to the browser history. I start at Clojure, I go > off exploring, I find myself on some node with no obvious direct edge > to something I was looking at before. If I could hit 'up' and go back > in the history to the last thing connected to what I'm focused on... > > Maybe I just need to spend more time with it and just get used to the > way it works now... I think 'up' and 'back' here are synonymous. Perhaps you're hoping for an 'up' that was equivalent to two 'back' actions…? The way I think of it, there is a graph (defined by the ontology) that includes all concepts, vars, and classes in Clojure and its library. It's highly-connected, with cycles all over the place. Sanely visualizing it requires that we restrict our visible scope over that graph, as if it were wrapped onto a sphere that we were rotating each time we focus on a different node. Perhaps what might be useful is a quick way to show the graph of nodes you've visited in the current session -- breadcrumbs of a sort, but shown in the graph itself so you can easily peek back at docs and (once I implement it) inspect the connecting edges? >> As you say, 1.2.0 contrib is large, but "new contrib" is likely to get much, >> much larger (presumably larger than the standard library) since contributing >> to it is far easier than classic contrb. > > Really? I thought "new contrib" was more tightly controlled and > subject to more Clojure/core approval. Mind you, we had ~60 old > contrib libraries and we already have close to 30 new contrib > libraries so you may well be right... Controlled, yes, but for quality, not size. Contributing to classic contrib was much more difficult than it is to contribute to "new contrib", so I have to believe that the latter will be far larger in relatively short order, while being of far higher quality at the same time. - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
I am new comer for clojure, I concern that when will clojure surpport Distribution function like erLang
I am new comer for clojure, I concern that when will clojure surpport Distribution function like erLang yeah, the up is my question. and I want to know is there any roadmap for clojure ? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
> For example Common Lisp does support this. That's not true, or at least it's only partly true. Here's a translation of your example into Common Lisp (I added a use of a# in the macro to avoid compiler optimization making the problem go away): (defun f (x) (lambda () x)) (defparameter foo (f 0)) (defmacro bar () `(let ((a# ,foo)) a#)) (defun call-bar () (bar)) I can compile this within a Lisp image (not compiling to file), and call call-bar with no problems. But if I try to compile to file, compilation fails with the error Object # is of type FUNCTION which is not externalizable Common Lisp's notion of externalizable objects (when compiling) is defined at http://www.lispworks.com/documentation/HyperSpec/Body/03_bda.htm. Regards, Simon -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in macros
On 4 Mag, 01:34, Chris Perkins wrote: > On May 3, 5:22 pm, André Thieme wrote: > > > Some of the limitations: > > 1. (defmacro x [] `(let [a# ~(atom 0)])) > > > 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link > > > 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) > > > All three calls fail, (x) and (y) and (z). > > I see no plausible reason why it *should* be that way. > > I do - because most of the time, embedding an object in code is > accidental, caused by messing up the quoting and unquoting. I would > prefer that evaling something that cannot be produced by the reader be > an error. > > I can see that in some cases, having eval pass unexpected types > through unchanged can be useful, but I think it would be much more > common for it to result in hard-to-debug errors, especially for > beginning macro writers. Code-is-data is the quintessential feature of Lisp. That some code cannot be produced by the reader is, at most, a limitation of the reader, not a reason for making that code illegal. It can, sure, be a source of errors, but no more than forgetting to quote or unquote a symbol in a macro expansion already is. Including closures in compiled classes is not trivial, but still technically doable, and since as André demonstrated that it's the basis for certain advanced macro techniques, imho it's a feature that should not be missing from a powerful, stable, widely used Lisp like Clojure. Alessio -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Java dependency injection in Clojure
On 4 Mag, 06:53, Luc Prefontaine wrote: > Hi, > > being tired of wandering through a few thousand lines of XML Spring bean > definitions, I finally wrote a library > to start moving away from Spring/XML. It's definitively nicer doing > dependency injection/auto-wiring using Clojure. > > This is part of our global effort here to confine Java as much as possible to > lower layers. > > Lacking imagination (or being lazy ?), I called it boing. The source code is > available athttps://github.com/lprefontaine/Boing > and the Wiki there describes its scope and capabilities. > > It's a 1.0 version. It should make it to prod beginning of this summer. > > The jar is on Clojars ([org.clojars.lprefontaine/boing "1.0"] in leiningen). > > It may be of interest to people having mixed environments and potentially to > some using external Java libraries. > It's much more dynamic than XML and significantly shorter. Look at the > examples folder. > > Comments are welcomed. The TODO list is not yet published but we see a few > things we want to add to it especially > in the area of resource management and some optimizations. > > Code wise I think it's not too horrible given that I had to squeeze this in > my already ultra-tight schedule in > the last three weeks or so. That's really nice! I did something similar in Common Lisp, called DynaSpring [1]. I think this kind of thing fits Lisp perfectly, and it's nice to see an implementation of similar ideas in Clojure. Perhaps we can mutually take inspiration from each other's projects and, why not, even share some code and ideas. Right now I'm not actively developing it because I'm no longer using Spring at work, but still I like the concept and hope to use it on a real project sooner or later. I wish you well for boing! Alessio [1] code.google.com/p/dynaspring/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Proposal: Ensure that c.c.lazy-xml/emit outputs XML
Hello. In clojure-contrib 1.2, lazy-xml/emit outputs XML in most cases. However, if it gets HTML or similar format data, the output format is switched to HTML. That makes some differences at least on OpenJDK6. 1. In XML mode, output doesn't contain any extra \n if :indent is skipped. In HTML mode, it contains. 2. In HTML mode, the XML declaration is skipped. 3. In HTML mode, extra is inserted automatically. I think that really harmful thing is only 3. because the output is always invalid XML with unnecessary data, but all of them surprise me, anyway. Is this an intended behavior? If not, inserting (.setOutputProperty trans "method" "xml") around 144-156 may fix it. I'm sorry if it is already fixed on the repository. Thank you. -- Name: OGINO Masanori (荻野 雅紀) E-mail: masanori.og...@gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lacij v.0.1 a graph visualization library
project.clj was missing during the first commit. It's corrected, you should be able to use "lein run -m" to run examples. 0.1.0-SNAPSHOT is effectively 0.1.0 ill-named but since I notice that the anelemma library was removed from Clojars, I added my own version and updated all dependencies. If you want to use Clojars the current version is now [lacij "0.1.2"]. If you have any further problem feel free to open an issue on the project page or contact me directly. On May 3, 7:33 pm, Ambrose Bonnaire-Sergeant wrote: > Hi Pierre > > This looks very cool, I'd love to try it. > > The version on clojars is 0.1.0-SNAPSHOT, could you upload 0.1.0? > > How do you build it from source? I can't locate a build script. > > Thanks, > Ambrose > > On Tue, May 3, 2011 at 9:26 PM, Pierre Allix < > > > > > > > > pierre.allix.w...@googlemail.com> wrote: > > Hello, > > > I would like to announce the version 0.1 of the Lacij library, > > a graph visualization library written in Clojure. > > > I would be really happy with any feedbacks and comments, on the code > > or the architecture. Help is welcome to implement additional layout > > algorithms. > > > From the README file: > > > Lacij is a graph visualization library written in Clojure. It allows > > the display > > and the dynamic modification of graphs as SVG documents that can be > > viewed > > with a Web browser or with a Swing component. Undo/redo is supported > > for the > > dynamic modification. Automatic layout is provided for the > > visualization. > > The library is available on GitHub: > > >https://github.com/pallix/lacij > > > and on Clojars: > > >http://clojars.org/lacij > > > This library is being developed as part of the Carneades project: > > >http://carneades.berlios.de/ > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
