Re: [RFC] Roundtripping namespaced xml documents for data.xml
2014-05-23 19:01 GMT+02:00 Paul Gearon :
>
> I still argue for using keywords here. The existing API uses them, and
> they're a natural fit.
>
The fact that they have established meaning (for denoting literal xml names
+ their prefix in a given serialization) in the API is exactly one of my
reasons for not wanting to change those semantics. Having a separate tier
for representing raw, serialized xml is fine. It's what the library
currently does. Adding new behavior, like proper xml namespacing, warrants
adding a new tier.
> The one real problem is elements would need a special hash/equality check
> to deal with namespace contexts (presuming that fn:deep-equal maps to
> Object.equals).
>
I had been thinking along those lines before. Check out the dev thread, I
try to argue that at first there, but at some point I realized that it
makes no sense to strictly stick to the raw representation and compute
other info just on the fly. The key observation is, that a tree of raw,
prefixed xml doesn't make any sense without xmlns declarations, whereas
they are redundant, as soon as the tree has been resolved.
To your point from below:
> I didn't follow the discussion for putting URIs into keywords, as I could
> not see why we would want this (am I missing something obvious?)
>
We need the URIs for xml processing and the XmlNamespace metadata can get
lost or not be there in the first place. Also the URI counts for equality,
see below.
I totally agree that it makes no sense putting them in keywords.
> The keywords would need to be translated according to the current
> context. However, that approach still works for fragments that can be
> evaluated in different contexts,
>
The problem are fragments that are taken out from their (xmlns - declaring)
root-element and/or that have no XmlNamespace metadata. Apart from actual
prefix assignment (which can be done in the emitter), QNames are completely
context free in that regard. See the key observation above.
> while storing URIs directly needs everything to be rebuilt for another
> context.
>
Are you talking about prefix assignments? See my comment about diffing
metadata below. I also detailed on this point in the design page.
Most possible QNames can be directly expressed as a keyword (for instance,
> the QName 㑦:㒪 can be represented as the read-able keyword :㑦/㒪). The
> keyword function is just a workaround for exotic values. While I know they
> can exist (e.g. containing \u000A), I've yet to see any QNames in the wild
> that cannot be represented as a read-able keyword.
>
Seen xhtml? What about the QName {http://www.w3.org/1999/xhtml}body? Notice
that :http://www.w3.org/1999/xhtml/body would be read like (keyword "http:"
"/www.w3.org/1999/xhtml/body"). Another point that's already been made on
the dev thread.
> In case I'm not clear, say I have these two docs:
>
> http://ex.com/"; xmlns:a="http://a.com/";>
> http://b.org"; b:baz="blah"/>
>
>
> http://something.else.com/";>
> http://b.org"; b:baz="blah"/>
>
>
> If I compare the a:bar element form both documents with func-deep-equal
> then they should compare equal, despite the fact that the a:bar qname
> resolves differently in each context.
>
Are you saying that deep-equals compares the actual serialization (with
prefixes), or that the default equality should do that?
If so, please read the infoset specification:
http://www.w3.org/TR/xml-infoset/#infoitem.element
The relevant quote for this case:
*[prefix]* The namespace prefix part of the element-type name. If the name
> is unprefixed, this property has no value. Note that namespace-aware
> applications should use the namespace name rather than the prefix to
> identify elements.
> I still don't see why the reverse mapping is needed. Is it because I'm
> storing the QName in a keyword and can look up the current namespace for
> the URI, while you are storing the fully qualified name?
>
First, terminology: In xml the namespace _is_ the uri. The thing that you
write before the : in the serialization is a prefix. It is only an artifact
of serialization, completely meaningless except when you actually read or
write xml. So I want the user to be to "write" xml without javax.xml, just
by transforming the tree back to its context-dependent keyworded
prefix-representation. So we need a way to find the (a) current prefix for
a namespace.
Sorry, I'm not following what you were getting at with this. In this
> example D and E both get mapped to the same namespace, meaning that
> and can be made to resolve the same way. But in a
> different context they could be different values.
>
Which is the reason we need to lift elements out of their context as soon
as possible. We don't want an element to change its namespace, just because
we transplant it into another xml fragment. Chouser went to great length
about this point, before he realized that this was exactly my goal aswell.
If both the explicit declarations of namespaces on elements and current
> c
[ANN] monarch 0.2.0 - Simple database migrations for Clojure.
I realize that there are other database migration frameworks already availablefor clojure projects, but I always seem to run into issues pretty fast in trying to use them. This is also the first plugin I've developed and made publicly available, so I'd love some feedback! I've been using Clojure for a while now but I don't really have anyone mentoring me :). https://github.com/mcramm/monarch -- 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/d/optout.
Remote function calls / simple distributed computation
What are the ways to do remote function calls with Clojure? Here is a *low-level list* I have so far: * Java Remote Method Invocation API: http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/index.html * nREPL: https://github.com/clojure/tools.nrepl There are *higher-level tools*, too, such as: * Slacker https://github.com/sunng87/slacker What else should I add to the lists? Here is my goal. I'm exploring various ways to do distributed computation. Many distributed computation platforms (e.g. Storm, Hadoop) require (1) significant dev-ops setup (2) deployment via a JAR file (3) quite a bit of time lag to get things started. I was hoping to find lighter-weight, more responsive, ways to do distributed computation. I also consider this a learning exercise. I like PigPen's use of a custom `pmap` function to distributes work: https://github.com/Netflix/PigPen (But it requires Pig and Hadoop) It could be nifty to have a `pmap` that worked, say, over a set of machines connected via nREPL. Has this already been done? Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To 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/d/optout.
dynamic java obj construction from classname string
Hi, I'm trying to construct a Java obj from a from a classname string. I've managed to import the thing using a macro: (defmacro import-by-name [name] `(import [~name])) (let [klass-name "foo.bar.Baz" the-ns (import-by-name klass-name) the-obj (new foo.bar.Baz arg)] ...) But when I use a string instead of literal arg to new I get "Unable to resolve classname": ... the-obj (eval `(new ~klass-name ~arg)) ...] The error message has the right classname, which is in test/classes as expected (leiningen proj.). So I can use a string to import the class, but not to create an object of the class. What am I doing wrong? Thanks, Gregg -- 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/d/optout.
Re: dynamic java obj construction from classname string
On Sunday, 25 May 2014 22:45:27 UTC+5:30, Gregg Reynolds wrote: > > Hi, > > I'm trying to construct a Java obj from a from a classname string. > I've managed to import the thing using a macro: > > (defmacro import-by-name [name] `(import [~name])) > (let [klass-name "foo.bar.Baz" >the-ns (import-by-name klass-name) >the-obj (new foo.bar.Baz arg)] ...) > > > But when I use a string instead of literal arg to new I get "Unable to > resolve classname": > ... > the-obj (eval `(new ~klass-name ~arg)) > Instead of ~klass-name, try ~(symbol klass-name) or ~(Class/forName klass-name). HTH Shantanu -- 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/d/optout.
non-literate, excellent documentation style
Giving my LP horse a rest I'd like to call your attention to backbone.js and the way they arrange documentation. It is less of a "story" form or "why" explanation and more on the details which are not apparent in the code. I don't know what tool was used to create it. http://backbonejs.org/docs/backbone.html Tim Daly -- 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/d/optout.
Re: non-literate, excellent documentation style
Based on the name of the css file I'd say they use http://jashkenas.github.io/docco/ ;) Marek On Sunday, May 25, 2014 9:45:19 PM UTC+2, da...@axiom-developer.org wrote: > > Giving my LP horse a rest I'd like to call your attention > to backbone.js and the way they arrange documentation. > > It is less of a "story" form or "why" explanation and > more on the details which are not apparent in the code. > > I don't know what tool was used to create it. > > http://backbonejs.org/docs/backbone.html > > Tim Daly > > -- 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/d/optout.
Re: non-literate, excellent documentation style
Yes, it is based on docco http://jashkenas.github.io/docco/ Check https://github.com/jashkenas/backbone/blob/master/package.json the doc scripts is "doc": "docco backbone.js && docco examples/todos/todos.js examples/backbone.localstorage.js", On Sun, May 25, 2014 at 4:51 PM, Marek Srank wrote: > Based on the name of the css file I'd say they use > http://jashkenas.github.io/docco/ ;) > > Marek > > > On Sunday, May 25, 2014 9:45:19 PM UTC+2, da...@axiom-developer.org wrote: >> >> Giving my LP horse a rest I'd like to call your attention >> to backbone.js and the way they arrange documentation. >> >> It is less of a "story" form or "why" explanation and >> more on the details which are not apparent in the code. >> >> I don't know what tool was used to create it. >> >> http://backbonejs.org/docs/backbone.html >> >> Tim Daly >> >> -- > 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/d/optout. > -- 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/d/optout.
Re: non-literate, excellent documentation style
There are also Clojure tools to generate documentation like this: https://github.com/gdeer81/marginalia On 25 May 2014 20:55, Angel Java Lopez wrote: > Yes, it is based on docco > http://jashkenas.github.io/docco/ > Check > https://github.com/jashkenas/backbone/blob/master/package.json > the doc scripts is > "doc": "docco backbone.js && docco examples/todos/todos.js > examples/backbone.localstorage.js", > > > On Sun, May 25, 2014 at 4:51 PM, Marek Srank wrote: > >> Based on the name of the css file I'd say they use >> http://jashkenas.github.io/docco/ ;) >> >> Marek >> >> >> On Sunday, May 25, 2014 9:45:19 PM UTC+2, da...@axiom-developer.orgwrote: >>> >>> Giving my LP horse a rest I'd like to call your attention >>> to backbone.js and the way they arrange documentation. >>> >>> It is less of a "story" form or "why" explanation and >>> more on the details which are not apparent in the code. >>> >>> I don't know what tool was used to create it. >>> >>> http://backbonejs.org/docs/backbone.html >>> >>> Tim Daly >>> >>> -- >> 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/d/optout. >> > > -- > 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/d/optout. > -- 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/d/optout.
Macro and metadata
I see that macro are defined with associated metadata :macro true in its associated var. Evaluate: (meta (var defn)) and you see the :macro true in metadata Why? In other lisp, macro are the result of evaluate (mlambda ... ) or something alike, that is, macro are values that are evaluated in an special way, as special forms (no evaluation of arguments) and then, the result is evaluated. Normal functions are (lambda ) like (fn ) in Clojure. As macros are values, they can be passed as arguments (map amacro ) could be evaluated (I guess). In Clojure, you must write (map (var amacro) ... ) Why in Clojure the macro are defined using metadata, instead of something like (mlambda ... ) or (mfn ... )? My first guess: this way of doing macro was related with compile to Java Angel "Java" Lopez @ajlopez -- 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/d/optout.
Re: dynamic java obj construction from classname string
On Sun, May 25, 2014 at 2:00 PM, Shantanu Kumar wrote: > > > On Sunday, 25 May 2014 22:45:27 UTC+5:30, Gregg Reynolds wrote: >> >> Hi, >> >> I'm trying to construct a Java obj from a from a classname string. >> I've managed to import the thing using a macro: >> >> (defmacro import-by-name [name] `(import [~name])) >> (let [klass-name "foo.bar.Baz" >>the-ns (import-by-name klass-name) >>the-obj (new foo.bar.Baz arg)] ...) >> >> >> But when I use a string instead of literal arg to new I get "Unable to >> resolve classname": >> ... >> the-obj (eval `(new ~klass-name ~arg)) > > > Instead of ~klass-name, try ~(symbol klass-name) or ~(Class/forName > klass-name). Many thanks.Class/forName works great. Thanks, gregg -- 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/d/optout.
Re: Macro and metadata
A macro is a function that's evaluated at compile time rather than at runtime. Clearly the compiler needs some mechanism to distinguish between the two, correct? Clojure already has metadata and functions, so using a metadata flag on the var introduces no new types. It also has the advantage of being able to resolve a symbol as a macro before retrieving its content. It's not the only way Clojure could have distinguished macros from normal functions, but it's a simple and efficient solution. - James On 25 May 2014 23:20, Angel Java Lopez wrote: > I see that macro are defined with associated metadata :macro true in its > associated var. > > Evaluate: > > (meta (var defn)) > > and you see the :macro true in metadata > > Why? In other lisp, macro are the result of evaluate (mlambda ... ) or > something alike, that is, macro are values that are evaluated in an special > way, as special forms (no evaluation of arguments) and then, the result is > evaluated. Normal functions are (lambda ) like (fn ) in Clojure. > As macros are values, they can be passed as arguments (map amacro ) > could be evaluated (I guess). In Clojure, you must write (map (var amacro) > ... ) > > Why in Clojure the macro are defined using metadata, instead of something > like (mlambda ... ) or (mfn ... )? > > My first guess: this way of doing macro was related with compile to Java > > Angel "Java" Lopez > @ajlopez > > -- > 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/d/optout. > -- 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/d/optout.
Re: non-literate, excellent documentation style
Unfortunately, marginalia has a lot of unresolved issues, bugs and limitations, but it was a good first step in this direction for the Clojure community. On Sun, May 25, 2014 at 2:34 PM, Daniel Kersten wrote: > There are also Clojure tools to generate documentation like this: > https://github.com/gdeer81/marginalia > > > On 25 May 2014 20:55, Angel Java Lopez wrote: > >> Yes, it is based on docco >> http://jashkenas.github.io/docco/ >> Check >> https://github.com/jashkenas/backbone/blob/master/package.json >> the doc scripts is >> "doc": "docco backbone.js && docco examples/todos/todos.js >> examples/backbone.localstorage.js", >> >> >> On Sun, May 25, 2014 at 4:51 PM, Marek Srank wrote: >> >>> Based on the name of the css file I'd say they use >>> http://jashkenas.github.io/docco/ ;) >>> >>> Marek >>> >>> >>> On Sunday, May 25, 2014 9:45:19 PM UTC+2, da...@axiom-developer.orgwrote: Giving my LP horse a rest I'd like to call your attention to backbone.js and the way they arrange documentation. It is less of a "story" form or "why" explanation and more on the details which are not apparent in the code. I don't know what tool was used to create it. http://backbonejs.org/docs/backbone.html Tim Daly -- >>> 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/d/optout. >>> >> >> -- >> 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/d/optout. >> > > -- > 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/d/optout. > -- 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/d/optout.
Re: [ANN] monarch 0.2.0 - Simple database migrations for Clojure.
Is there a reason why DATABASE_URL isn't in the project config? I guess a more relevant question would be to ask if there's something like a local config file for leiningen projects? Something that is per-project but ideally ignored by the VCS. Something that you can use to override what's inside the project.clj. On Sat, May 24, 2014 at 7:27 PM, Michael Cramm wrote: > I realize that there are other database migration frameworks already > availablefor clojure projects, but I always seem to run into issues pretty > fast in trying to use them. > > This is also the first plugin I've developed and made publicly available, > so I'd love some feedback! I've been using Clojure for a while now but I > don't really have anyone mentoring me :). > > https://github.com/mcramm/monarch > > -- > 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/d/optout. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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/d/optout.
Re: Remote function calls / simple distributed computation
I realize it's not exactly what you are looking for, but perhaps a pmap-like implementation can easily be built using a distributed message queue. The tricky part would be to ensure the functions to be distributed can be safely serialized/deserialized. (Not doing I/O or using other shared resources, etc...) On Sun, May 25, 2014 at 4:29 PM, David James wrote: > What are the ways to do remote function calls with Clojure? Here is a > *low-level > list* I have so far: > * Java Remote Method Invocation API: > http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/index.html > * nREPL: https://github.com/clojure/tools.nrepl > > There are *higher-level tools*, too, such as: > * Slacker https://github.com/sunng87/slacker > > What else should I add to the lists? > > Here is my goal. I'm exploring various ways to do distributed computation. > Many distributed computation platforms (e.g. Storm, Hadoop) require (1) > significant dev-ops setup (2) deployment via a JAR file (3) quite a bit of > time lag to get things started. I was hoping to find lighter-weight, more > responsive, ways to do distributed computation. I also consider this a > learning exercise. > > I like PigPen's use of a custom `pmap` function to distributes work: > https://github.com/Netflix/PigPen (But it requires Pig and Hadoop) > > It could be nifty to have a `pmap` that worked, say, over a set of > machines connected via nREPL. Has this already been done? > > Thanks! > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To 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/d/optout. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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/d/optout.
[ASK] How to unify methodological prototyping with implementation in reality (aka in cascalog)?
Hi everybody, I have been doing some random machine learning doodling and have always been haunted with this problem. When I just wanna set out and try if my methodology would work, I would program in Clojure aiming at a small dataset available within one single host memory (or even just doodle R or Python. I know what's blasphemy). When I wanna implement the results, I would usually have to re-write the whole process in Cascalog just in order to apply them in Hadoop data. I know I can still just start up to write Hadoop functions. But that's a bit overshoot since I have to run simulation study to verify the performance, correctness etc before even going into production development. Besides, having hadoop in memory to sit between my program and the computer just slows down computation. I've day-dreamed a lot some smart ways to do prototyping and, with the flip of a switch, my functions just become easily applicable to Hadoop data. Wondering if there's any ways to do that? I actually asked around and some one who I admire a lot suggested writing a Hadoop emulator-like wrapper for my input data. Wondering if there's an easier way? I would appreciate any input. Thanks. Hesen -- 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/d/optout.
Re: [ASK] How to unify methodological prototyping with implementation in reality (aka in cascalog)?
If I'm not mistaken, PigPen allows you to execute queries locally, without a hadoop cluster etc. Does that solve your problem? https://github.com/Netflix/PigPen/wiki/Design-and-Features#testing-local-execution-and-debugging On Mon, May 26, 2014 at 3:26 AM, Hesen Peng wrote: > Hi everybody, > > I have been doing some random machine learning doodling and have always > been haunted with this problem. > > When I just wanna set out and try if my methodology would work, I would > program in Clojure aiming at a small dataset available within one single > host memory (or even just doodle R or Python. I know what's blasphemy). > > When I wanna implement the results, I would usually have to re-write the > whole process in Cascalog just in order to apply them in Hadoop data. I > know I can still just start up to write Hadoop functions. But that's a bit > overshoot since I have to run simulation study to verify the performance, > correctness etc before even going into production development. Besides, > having hadoop in memory to sit between my program and the computer just > slows down computation. > > I've day-dreamed a lot some smart ways to do prototyping and, with the > flip of a switch, my functions just become easily applicable to Hadoop > data. Wondering if there's any ways to do that? > > I actually asked around and some one who I admire a lot suggested writing > a Hadoop emulator-like wrapper for my input data. Wondering if there's an > easier way? I would appreciate any input. Thanks. > > Hesen > > -- > 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/d/optout. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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/d/optout.
