Re: Standard Practice for a Canned Lexer, Parser, Analyzer?
Hello, 2010/1/29 Liam : > Could someone educate me about what developers normally do when faced > with having to create a lexer / parser / analyzer, say for clojure? > > Why would people go with a canned solution, i.e. ready-made like soup > out of a can, instead of by hand? > > E.g. why did the Counterclockwise Eclipse plug-in for Clojure use > ANTLR , Concerning Counterclockwise, it's simple: a combination of reasons * I wanted to play with ANTLR since we were also using it at work * Not much of Counterclockwise was written in clojure at that time Note that currently, there's a joint effort to provide clojure-based parsing for Counterclockwise : I'm working to create a port of paredit during my spare time, currently using a hand-written clojure parser (YAHWCP Yet Another Hand Written Clojure Parser - not a reader, a parser which produces a parsetree), and Christophe Grand is working on the general solution of providing a parser generator. > or why did in the Enclojure NetBeans plug-in for clojure use > JFLEX? Why in clojure itself is there a reader made by hand and not > using a canned generator? > > Am I naive in thinking one should do that by hand? Is this archaic > thinking like those who still prefer building websites in HTML by > hand? Note there is the fnparse library, too ( http://github.com/joshua-choi/fnparse ) > What's the advantage of doing that, say for clojure or in general? You > still have to learn how a given generator works. And you may be > limited by its design. What if you want fine combed control over how > things are parsed to get, for example, sophisticated syntax based > evaluation or inferences from cold code. E.g. like what Eclipse does > for Java and their “Java Models” and exhaustive “Abstract Syntax Tree” > nodes? > > I hope some of you could be generous enough to enlighten me. I'm not sufficiently expert in the subject to give you this enlightenment, sorry. P.S. : what is a cold node ? >From the vocabulary you're using, one could infer you're not a beginner on the subject, so certainly you could do well with any tool. I guess one of the purposes of such tools is to guide the users by providing "built-in semantics" for thinking about the problem domain. Another purpose may be that those tools provide more "declarative" ways to define their grammars. -- Laurent -- 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: Question: Clojure & concurrency in large-scale problems.
On 29 Jan 2010, at 08:37, Mike Meyer wrote: Which brings me to my question: how does clojure deal with concurrency at the inter-process level? At the inter-system level? Are their distributed versions of refs & atoms and the like available somewhere? No. Or perhaps the answer should be "not yet". You can of course use the various Java tools out there for inter-process communication and synchronization, but I am not aware of anything specific to Clojure. Konrad. -- 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: Standard Practice for a Canned Lexer, Parser, Analyzer?
Hello Laurent, Thank you very much for your answers and maintaining CCW. I was partially encouraged to use Eclipse (a while back) due to the existence of CCW (or clojure-dev as it was then). I wrote: […] sophisticated syntax based evaluation or inferences from “cold code” [...] not node. This is just my personal language in referring to evaluating code from its parse tree. In my mind, code when on the screen being edited: it is cold. But when run through the clojure compiler: it is hot. My understanding of programming is completely intuitive not formally taught. So, I may know some stuff by personal research, but my education is not computer science, and my work experience is not in programming. I have been interested in the subject for nearly 20 years now as an “armchair programmer”. I only manged to skew my education a little towards that, and I managed to make some of my work experience in IT project management systems. Only this year (with the US recession) did this interest become more involved for me than just a part-time hobby. I often end-up feeling that I don't know what other programmers seem to “just know” due to their direct work experience or education. I very much appreciated your encouragement above. Thanks again. -- 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: more lazy "fun"
Hello!
On 29 Jan., 03:49, Sean Devlin wrote:
> I'd do one thing differently than Tim. (partial = something) is a
> clojure smell. It's more idiomatic to use a set
>
> (if (some #{"foo"} ["foo" "bar"]) "yay" "humbug")
In my opinion, there really should be something like CL's FIND or
MEMBER in core (maybe both, since MEMBER is restartable but FIND
immediately returns the found element). I think using a set to achieve
this functionality is counter-intuitive (who thinks: Let's find an
element of a one element set within this collection when he just wants
to find something?)
There is #'includes? in seq-utils, but it isn't restartable and, as I
said, I think it belongs in core.
Regards
dhl
--
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: Standard Practice for a Canned Lexer, Parser, Analyzer?
Hello Liam
I'm neither an expert on this subject. :) Nevertheless I'll give you
my position.
Defining a new language, formally speaking, is very hard: you have to
define new symbols and rules. On many languages the same token can be
used in different contexts (think of "{" on Java: if blocks, method
blocks, class blocks: here the word "block" means very different
things). If you're going to write by hand you'll have to check all
these contextual points, and finally handle the validation process of
the source file as a whole.
Tools as ANTLR give you the chance to just specify the grammar
(allowed symbols and rules), leaving to them all the validation
checks. You can also give them a grammar and a set of events (called
"template" in ANTLR), which are automatically triggered by the parser
when it processes a given rule.
So this is the reason, in my opinion, of why the "by hand" way is not
very used. This topic is related to (external) Domain Specific
Languages, so maybe you can find interesting this:
http://martinfowler.com/articles/codeGenDsl.html#UsingTemplatesForGeneration.
Ciao
Roberto
On Fri, Jan 29, 2010 at 4:59 AM, Liam wrote:
> Could someone educate me about what developers normally do when faced
> with having to create a lexer / parser / analyzer, say for clojure?
>
> Why would people go with a canned solution, i.e. ready-made like soup
> out of a can, instead of by hand?
>
> E.g. why did the Counterclockwise Eclipse plug-in for Clojure use
> ANTLR , or why did in the Enclojure NetBeans plug-in for clojure use
> JFLEX? Why in clojure itself is there a reader made by hand and not
> using a canned generator?
>
> Am I naive in thinking one should do that by hand? Is this archaic
> thinking like those who still prefer building websites in HTML by
> hand?
>
> What's the advantage of doing that, say for clojure or in general? You
> still have to learn how a given generator works. And you may be
> limited by its design. What if you want fine combed control over how
> things are parsed to get, for example, sophisticated syntax based
> evaluation or inferences from cold code. E.g. like what Eclipse does
> for Java and their “Java Models” and exhaustive “Abstract Syntax Tree”
> nodes?
>
> I hope some of you could be generous enough to enlighten me.
>
> --
> 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: Standard Practice for a Canned Lexer, Parser, Analyzer?
I mean, the whole article: http://martinfowler.com/articles/codeGenDsl.html > http://martinfowler.com/articles/codeGenDsl.html#UsingTemplatesForGeneration. -- 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: more lazy "fun"
Hi,
On Jan 29, 10:52 am, DanL wrote:
> > (if (some #{"foo"} ["foo" "bar"]) "yay" "humbug")
>
> In my opinion, there really should be something like CL's FIND or
> MEMBER in core (maybe both, since MEMBER is restartable but FIND
> immediately returns the found element). I think using a set to achieve
> this functionality is counter-intuitive (who thinks: Let's find an
> element of a one element set within this collection when he just wants
> to find something?)
>
> There is #'includes? in seq-utils, but it isn't restartable and, as I
> said, I think it belongs in core.
http://groups.google.com/group/clojure/msg/f2585c149cd0465d
Sincerely
Meikel
--
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
Fwd: Berlin Lispers Meetup: February 2, 2010 - Clojure presentation
FYI: if anybody happens to be in berlin next week -- there is going to be an interesting presentation about clojure "in the cloud" ... tim Begin forwarded message: > From: Hans Hübner > Date: 2010-01-29 11:53:25 > To: lisp-ber...@googlegroups.com, lisp-ber...@lists.bknr.net, > lisp...@common-lisp.net, erlang-ber...@googlegroups.com > > Title: Berlin Lispers Meetup > Date: Tuesday February 2, 2010 > Time: 7pm onwards > Venue: New Thinking Store, Tucholskystr. 48, 10117 Berlin > Map: http://tinyurl.com/yk3nzdj (Google) > Transport: U-Bahn Oranienburger Tor, S-Bahn Oranienburger Straße > > You are kindly invited to the third "Berlin Lispers Meetup", an > informal gathering for anyone interested in Lisp, beer or coffee, > organized by Willem Broekema and Hans Hübner. > > This time, the meeting will take place in the New Thinking Store (see > address above), as we have a presentation by Stefan Richter of > freiheit.com who will talk about a Cloud-deployed web application > written in Clojure. The full title of his presentation is > > "Wie aus einem Clojure Pet-Projekt eine ausgewachsene Cloud-Computing > Web-App wurde. > Oder: > Was unterscheidet eigentlich eine Clojure Web-App von einer Anwendung > die in Java oder Common Lisp geschrieben ist?" > > Stefan will give his talk in German or English, depending on the > preference of the audience. It will start at 19:00h. > > Thanks go to Franz Inc. (http://franz.com/), the maker of Allegro > Common Lisp and the Allegrograph Web 3.0 database for sponsoring the > meeting by paying for the venue. > > Please join for another evening of parentheses (and brackets this time)! > > P.S.: If you are interested in given a Lisp related presentation on > one of our next meetings, please get in touch! > -- http://tim.lossen.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
Re: more lazy "fun"
Hello! On 29 Jan., 11:24, Meikel Brandmeyer wrote: > http://groups.google.com/group/clojure/msg/f2585c149cd0465d Rich has valid points but still, bad performance characteristics might be something that I, the user, should take responsibility for. I'm not sure if such considerations should prevent adding #'member or something to core, but then, I'm not Rich, and it's his baby. On the other hand, this is Lisp: in my Toolbox I can have what I want, even if other people deem it unnecessary or whatever, so it's not really a problem. Regards dhl -- 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
Exception handling functional style
Hi all I am trying to figure out some systematic and clear way how to handle exceptions in clojure and their bubbling up through the call chain. Let me illustrate it on some code examples (not executable, just to show the principle). (defn get-from-io [p] (access-external-source p)) (defn process-io [p] (let [response (get-from-io p) code (.getresponsecode response) message (.getmessage response)] (if (= code 0) do something) message)) (defn process-data [d] "process data, expecting something parsable" (let [p (parse d)] function p function p p)) (defn run [u] (process-data (process-io u))) Now, imagine the chain of calling functions is relatively big. Here it can all fall down on access-external-source causing an exception, but further up, maybe the message is scrambled, or pretty much anything. The question is, wrapping all function in try - catch does not make is clearer (from a processing point of view). Returning nil from broken functions just adds a boilerplate code all the way up. I could not find any guidelines of systematic approach of using "pure" functions in the mess of realworld. Thanks in advance Lukas -- 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: Using docs effectively (Ratio)
On Thu, Jan 21, 2010 at 7:57 AM, Jacek Generowicz wrote: > Clojure has a Ratio type; presumably there should be an easy way to > find the numerator and denominator of a Ratio object. > > I didn't have much luck on clojure.org or with find-doc, but > > (show 1/2) > > taught me that there are numerator and denominator methods on Ratio's > underlying Java implementation, so I can now do: > > (.numerator 1/2) ; => 1 > (.denominator 1/2) ; => 2 > > Is there a more direct way? (Not that this is bad! But you can't > use .numerator as a first-order function (though #(.numerator %) is > still pretty damn good).) > > In general, do you have any hints on how to go about looking for > useful Clojure functions which work with certain Clojure types ? > I'd welcome a patch that exposed these methods as functions in core. Rich -- 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: return value of use, requires?
On Thu, Jan 21, 2010 at 2:51 AM, Raoul Duke wrote: > hi, > > in the repl when i (use 'foo) vs. (use :foo) they both return nil, so > it doesn't help me know that the former is right and the latter isn't. > i think. would it be sensible for use to return true or something more > positive than nil if it successfully brings in a namespace? > > thanks. > Ok. Ticket (and patch) welcome. Rich -- 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: Proposal: New fn assoc-in-with
On Fri, Jan 22, 2010 at 8:57 AM, Chouser wrote: > On Thu, Jan 21, 2010 at 10:11 PM, Sean Devlin > wrote: >> Sometimes you don't want assoc-in to create a hash-map. Sometimes you >> wish it could create a sorted map. >> >> Just finished working on something with Alexy Khrabrov & Chouser on >> IRC, and the three of us are wondering if the result might be >> generally useful. >> >> (defn assoc-in-with >> "supply a default-map instead of a hash-map" >> [m default-map [k & ks] v] >> (if ks >> (assoc m k (assoc-in-as (get m k default-map) default-map ks v)) >> (assoc m k v))) > > As I mentioned in IRC, this could actually be a 4-argument > version of 'assoc-in' instead of a new function. Assuming of > course Rich likes the idea. > Where would the default go? Also, need it be a map, vs anything associative (e.g. a vector)? Rich -- 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: idiom question: infinite sequence as data source for many threads?
java.util.concurrent.LinkedBlockingQueue Check out the put() method. That what I used for a program similar to the original poster when I needed control over the number of threads. On Jan 28, 7:15 pm, Paul Mooser wrote: > This is something I run into with executors in Java periodically - I > have never understood why there isn't a default implementation > provided which has a blocking queue for tasks which will block on > submission to the queue if it is full. If I'm not mistaken, the > default ones which use bounded blocking queues throw rejected > execution exceptions if you submit too many tasks, or just let the > queue grow without bounds. > > It should be relatively easy to set up an executor with that behavior, > which would make it fairly easy to not produce things "too far" ahead > of consumption. > > On Jan 28, 6:53 am, Timothy Pratley wrote: > > > pooledExecutor is just a standard java fixed size thread pool based > > upon the number of processors available, so it will only create X > > threads at a time. However I believe that submitted jobs are queued so > > if your seq processing can get too far ahead you would end up with a > > very full queue. I'm sure there must be a way to limit the submission > > rate but can't think of it right now maybe someone else will chime in -- 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: Proposal: New fn assoc-in-with
The following doesn't currently work: user=> (assoc [] 1 :a) # So I say this should be map only. Granted, assoc-in already has this issue. Also, what do you mean by your question "Where would the default go"? I don't understand what you're getting at yet. Sean On Jan 29, 8:44 am, Rich Hickey wrote: > On Fri, Jan 22, 2010 at 8:57 AM, Chouser wrote: > > On Thu, Jan 21, 2010 at 10:11 PM, Sean Devlin > > wrote: > >> Sometimes you don't want assoc-in to create a hash-map. Sometimes you > >> wish it could create a sorted map. > > >> Just finished working on something with Alexy Khrabrov & Chouser on > >> IRC, and the three of us are wondering if the result might be > >> generally useful. > > >> (defn assoc-in-with > >> "supply a default-map instead of a hash-map" > >> [m default-map [k & ks] v] > >> (if ks > >> (assoc m k (assoc-in-as (get m k default-map) default-map ks v)) > >> (assoc m k v))) > > > As I mentioned in IRC, this could actually be a 4-argument > > version of 'assoc-in' instead of a new function. Assuming of > > course Rich likes the idea. > > Where would the default go? Also, need it be a map, vs anything > associative (e.g. a vector)? > > Rich -- 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: more constructors (to support default values) for deftype?
On Fri, Jan 22, 2010 at 5:41 PM, Raoul Duke wrote:
> hi,
>
> if i have (deftype map-db [next-id id-to-item-map]) i have to then do
> (map-db 0 {}) any time i want to make a new one. it would be nice to
> be able to add a function in my deftype so i could use (map-db) to get
> the same effect.
>
> ?
You can just write ordinary functions for that.
Rich
--
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: "recursive" deftype?
On Fri, Jan 22, 2010 at 6:58 PM, Raoul Duke wrote: >> So you just need to instead use (new Trec (+ 1 v)). > > thanks! that does work for me, too. > > (i'm hoping Clojure will be able to avoid having to do it that way in > the long run.) > That's as designed, and documented. Rich -- 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: update-in and get-in why no default?
On Dec 30 2009, 6:18 am, Timothy Pratley wrote: > On Dec 13, 1:24 am, Rich Hickey wrote: > > > fnil seems to me to have greater utility than patching all functions > > that apply functions with default-supplying arguments. > > Neat :) I like it. > > > The get-in function could be enhanced, and would mirror get. > > Should I interpret 'could' as 'patch welcome' or 'let me think about > it'? > Patches welcome for get-in, and my fnil. Thanks, Rich -- 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: Types in deftype vs. gen-class
On Fri, Jan 22, 2010 at 4:19 PM, Andreas Wenger wrote: > Hi, > > I read that deftype is often a better replacement for gen-class and > defstruct. Indeed, it would fit for my purposes very well, except the > following problem: deftype does not (yet?) use all the information > from type hints. > > Simple example: > > (:gen-class > :methods [[getText [] String]] ... > > compiles to: > > public java.lang.String getText(); > > But: > > (deftype ... [#^java.lang.String text]) > > compiles to: > > public final java.lang.Object text; > > Although the documentation states that "fields [...] can have type > hints", this seems to work only for primitive types at the moment. For > Java interop (using deftype-defined classes from Java code) however, > it may be crucial to have the right types. > > Will this feature be added, and if not, what is the best alternative > solution? > > Thank you! > > https://www.assembla.com/spaces/clojure/tickets/252-Support-typed-non-primitive-fields-in-deftype Rich -- 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: update-in and get-in why no default?
Rich, Your example didn't support a variadic signature. Is that the long term plan? Sean On Jan 29, 8:48 am, Rich Hickey wrote: > On Dec 30 2009, 6:18 am, Timothy Pratley > wrote: > > > On Dec 13, 1:24 am, Rich Hickey wrote: > > > > fnil seems to me to have greater utility than patching all functions > > > that apply functions with default-supplying arguments. > > > Neat :) I like it. > > > > The get-in function could be enhanced, and would mirror get. > > > Should I interpret 'could' as 'patch welcome' or 'let me think about > > it'? > > Patches welcome for get-in, and my fnil. > > Thanks, > > Rich -- 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: Proposal: New fn assoc-in-with
On Fri, Jan 29, 2010 at 8:44 AM, Rich Hickey wrote: > On Fri, Jan 22, 2010 at 8:57 AM, Chouser wrote: >> On Thu, Jan 21, 2010 at 10:11 PM, Sean Devlin >> wrote: >>> Sometimes you don't want assoc-in to create a hash-map. Sometimes you >>> wish it could create a sorted map. >>> >>> Just finished working on something with Alexy Khrabrov & Chouser on >>> IRC, and the three of us are wondering if the result might be >>> generally useful. >>> >>> (defn assoc-in-with >>> "supply a default-map instead of a hash-map" >>> [m default-map [k & ks] v] >>> (if ks >>> (assoc m k (assoc-in-as (get m k default-map) default-map ks v)) >>> (assoc m k v))) >> >> As I mentioned in IRC, this could actually be a 4-argument >> version of 'assoc-in' instead of a new function. Assuming of >> course Rich likes the idea. >> > > Where would the default go? Also, need it be a map, vs anything > associative (e.g. a vector)? Since update-in could use this pattern as well, I don't think the default should go after the value (or update fn) position. I think where Sean put it is fine -- after the collection, before the vector of keys. I don't see why it needs to be restricted to a map -- all the normal assoc rules apply. --Chouser http://joyofclojure.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: (list* ())
On Fri, Jan 22, 2010 at 4:55 PM, ataggart wrote: > > > On Jan 22, 1:30 pm, samppi wrote: >> This is not a big deal: it is a quibble with a weird and inconvenient >> behavior of list*: when given an empty sequence, it returns nil >> instead of the empty list. Why is this? According to list*'s >> documentation, list* should always return a list. > > Judging from the code for list*, as well as its usage in apply, I > infer the return value is supposed to adhere to seq semantics. What > issue were you having such that returning a nil (as opposed to an > empty list) was a problem? > Yes, list and list* date from the early days of Clojure when there was more conflation of lists and seqs, and should probably be better named seq-of and seq-of*. I'll have to think about whether list* is really possible (i.e. promising type of list), since the objective is to not copy the last arg. Rich -- 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: update-in and get-in why no default?
On Jan 29, 9:04 am, Sean Devlin wrote: > Rich, > Your example didn't support a variadic signature. Is that the long > term plan? > It's the short term plan. Let's see if there's any real need for more than three. I've never needed more than one. Rich -- 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
interesting puzzle
I saw this on twitter. http://pastie.org/796264 The problem: given a list of strings, produce a list where sequential non-empty strings are concatenated # Conditions: Do not use iteration. # # Example: glom (["a", "b", "c"]) = ["abc"] # glom (["a", "", "b"]) = ["a", "b"] # glom (["a", "b", "", "c"]) = ["ab", "c"] # glom (["a", "b", "", "", "c"]) = ["ab", "c"] The author had rules like, don't use iteration and avoid recursion. anyone have any clever solutions? My first reaction was to use reduce, but I'm not sure how that'd work. -- Omnem crede diem tibi diluxisse supremum. -- 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: interesting puzzle
Using seq-utils...
1. Assume " " is NOT empty
2. Use partition-by to split
3. Use remove to clean up
4. Map!
user=>(map (partial apply str)
(remove (comp empty? first)
(partition-by empty? ["a" "" "b" "c"])))
("a" "bc")
I think this satisfies you conditions.
Sean
On Jan 29, 10:25 am, Wilson MacGyver wrote:
> I saw this on twitter.
>
> http://pastie.org/796264
>
> The problem: given a list of strings, produce a list where sequential
> non-empty strings are concatenated
>
> # Conditions: Do not use iteration.
> #
> # Example: glom (["a", "b", "c"]) = ["abc"]
> # glom (["a", "", "b"]) = ["a", "b"]
> # glom (["a", "b", "", "c"]) = ["ab", "c"]
> # glom (["a", "b", "", "", "c"]) = ["ab", "c"]
>
> The author had rules like, don't use iteration and avoid recursion.
>
> anyone have any clever solutions? My first reaction was to use reduce, but
> I'm not sure how that'd work.
>
> --
> Omnem crede diem tibi diluxisse supremum.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
What is clojure.lang.Sequential good for?
In trying to figure out why clojure.contrib.seq-utils/flatten wouldn't work on my data type, I discovered the Java interface clojure.lang.Sequential and the associated test function clojure.core/ sequential?. However, the interface contains no methods. It is used in the Clojure source code only in "instanceof" tests before trying to apply RT.seq() to an object. Now I am wondering if my type should implement clojure.lang.Sequential or not. Doing so makes "flatten" work, which I like. But I am not sure if there are other effects that I would not like to have. My type already implements Seqable, so calling RT.seq() on it is fine. Konrad. -- 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: apply macro to 'argument' list?
On Thu, Jan 28, 2010 at 6:43 PM, Sean Devlin wrote: > Check the apply-macro namespace in contrib ah-hah! i really should have figured. 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
Re: Exception handling functional style
On Fri, Jan 29, 2010 at 4:24 AM, Lukas Lehner wrote: > The question is, wrapping all function in try - catch does not make is > clearer (from a processing point of view). Returning nil from broken > functions just adds a boilerplate code all the way up. > > I could not find any guidelines of systematic approach of using "pure" > functions in the mess of realworld. i suspect monads could be helpful here, if you go for that kind of thing. -- 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: apply macro to 'argument' list?
Just linking this diskussion to an earlier one: http://groups.google.com/group/clojure/browse_thread/thread/b38a2754fd5b8104/fcd7c578238622f5 -- 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: more lazy "fun"
Hi, Am 29.01.2010 um 12:57 schrieb DanL: CL find as I understand it: (some (partial = x) some-coll). Sufficiently ugly to show performance characteristics. CL member as I understand it: (drop-while (partial not= x) some-coll). Sufficiently ugly to show performance characteristics. Sincerely Meikel -- 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: more lazy "fun"
Hi,
Am 29.01.2010 um 03:49 schrieb Sean Devlin:
> I'd do one thing differently than Tim. (partial = something) is a
> clojure smell. It's more idiomatic to use a set
>
> (if (some #{"foo"} ["foo" "bar"]) "yay" "humbug")
This will fail if the collection is allowed to contain nil or false.
Sincerely
Meikel
--
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 box 1.0 failed to connect to emacs server
Seconded. I have the same problem on win7, augmented by the fact that emacs spawns thousands of cmdproxy.exe... Depending on your machine capabilities, the only thing to do then is a hot reboot (try killing 5000 processes with new ones starting off every second). Works fine on winxp though... On Jan 19, 3:29 am, limux wrote: > when i start the clojure box 1.0, theemacsclient window stay on the > top of all the other windows, eventually it display a message "** > ERROR ** Timeout wating for server", but 1.0RC1 no that issue. -- 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: interesting puzzle
Hi, Am 29.01.2010 um 16:25 schrieb Wilson MacGyver: > I saw this on twitter. > > http://pastie.org/796264 > > The problem: given a list of strings, produce a list where sequential > non-empty strings are concatenated > > # Conditions: Do not use iteration. > # > # Example: glom (["a", "b", "c"]) = ["abc"] > # glom (["a", "", "b"]) = ["a", "b"] > # glom (["a", "b", "", "c"]) = ["ab", "c"] > # glom (["a", "b", "", "", "c"]) = ["ab", "c"] > > > The author had rules like, don't use iteration and avoid recursion. > > anyone have any clever solutions? My first reaction was to use reduce, but > I'm not sure how that'd work. I don't know the definition of iteration, but for my (naive, hobbyist) understanding you won't get around it. Recursion is just another form. A map call is just another form. A reduce call is just another form. You have to walk the sequence in one way or the other and I would call that „iteration“. But I called the shot already in the sieve thread. So I will shut up now. Please enlighten me if this is totally wrong. Here a recursive definition. (defn glom [coll] (lazy-seq (when-let [s (seq coll)] (let [[items tail] (split-with (complement empty?) s) tail (drop-while empty? tail)] (cons (apply str items) (glom tail)) Sincerely Meikel -- 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: interesting puzzle
I had assumed when he wrote "do not use iteration", what he meant is to "not use for/next loop" otherwise, as you said, we can't solve the problem without examining the sequence. On Fri, Jan 29, 2010 at 2:38 PM, Meikel Brandmeyer wrote: > Hi, > > Am 29.01.2010 um 16:25 schrieb Wilson MacGyver: > >> I saw this on twitter. >> >> http://pastie.org/796264 >> >> The problem: given a list of strings, produce a list where sequential >> non-empty strings are concatenated >> >> # Conditions: Do not use iteration. >> # >> # Example: glom (["a", "b", "c"]) = ["abc"] >> # glom (["a", "", "b"]) = ["a", "b"] >> # glom (["a", "b", "", "c"]) = ["ab", "c"] >> # glom (["a", "b", "", "", "c"]) = ["ab", "c"] >> >> >> The author had rules like, don't use iteration and avoid recursion. >> >> anyone have any clever solutions? My first reaction was to use reduce, but >> I'm not sure how that'd work. > > I don't know the definition of iteration, but for my (naive, hobbyist) > understanding you won't get around it. Recursion is just another form. A map > call is just another form. A reduce call is just another form. You have to > walk the sequence in one way or the other and I would call that „iteration“. > But I called the shot already in the sieve thread. So I will shut up now. > Please enlighten me if this is totally wrong. > > Here a recursive definition. > > (defn glom > [coll] > (lazy-seq > (when-let [s (seq coll)] > (let [[items tail] (split-with (complement empty?) s) > tail (drop-while empty? tail)] > (cons (apply str items) (glom tail)) > > Sincerely > Meikel > > -- > 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 -- Omnem crede diem tibi diluxisse supremum. -- 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: Exception handling functional style
On Jan 29, 4:24 am, Lukas Lehner wrote: > The question is, wrapping all function in try - catch does not make is > clearer (from a processing point of view). Returning nil from broken > functions just adds a boilerplate code all the way up. In my opinion one should only catch those exceptions one is prepared to handle. Bear in mind that there are two main forms of exception: checked exceptions and unchecked exceptions (with Exception and RuntimeException being the common parent classes, respectively). My preference is to avoid checked exceptions in my code, and in those cases where an API I'm using may throw checked exceptions, to simply wrap it in an unchecked exception, and then throw it. -- 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: interesting puzzle
Hi, Am 29.01.2010 um 20:45 schrieb Wilson MacGyver: > I had assumed when he wrote "do not use iteration", > what he meant is to "not use for/next loop" That's how I understood it. Especially since all solutions at the pastie link more or less use recursion. (Even when they cheat and call out to a library. Then the recursion happens there...) Anyhow: Nice exercise. :) Sincerely Meikel -- 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: Using docs effectively (Ratio)
Patch submitted https://www.assembla.com/spaces/clojure/tickets/254-Expose-c-l-Ratio-s-accessors -- 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: more lazy "fun"
That's a great point. A contains? should be used in that case.
On Jan 29, 2:14 pm, Meikel Brandmeyer wrote:
> Hi,
>
> Am 29.01.2010 um 03:49 schrieb Sean Devlin:
>
> > I'd do one thing differently than Tim. (partial = something) is a
> > clojure smell. It's more idiomatic to use a set
>
> > (if (some #{"foo"} ["foo" "bar"]) "yay" "humbug")
>
> This will fail if the collection is allowed to contain nil or false.
>
> Sincerely
> Meikel
--
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: more lazy "fun"
Hello! On 29 Jan., 20:14, Meikel Brandmeyer wrote: > CL find as I understand it: (some (partial = x) some-coll). Sufficiently ugly > to show performance characteristics. > CL member as I understand it: (drop-while (partial not= x) some-coll). > Sufficiently ugly to show performance characteristics. Yes, that's basically it. A minor difference: CL:FIND returns the first matching element, so it's more like (first (drop-while (partial not= x) some-col))), but that doesn't really matter, because there are fundamental differences in design anyway. Things like: (find 1337 list :key #'cadr :test #'id) would be done differently in clojure, and also in CL one should probably structure ones code differently, but in the heat of the battle there are sometimes situations where this stuff might be handy (at least in my case). The problem was not the implementation, but I didn't understynd why something akin to member/find is not part of the core language. "Sufficiently ugly" surely is well put; having read the post linked above made me understand the reasoning behind it. Regards dhl -- 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: Exception handling functional style
Monads, I knew I cannot avoid them after all. I've tried digging into the two main clojure-monad tutorials but got kinda lost, repeatedly. So, if they (monads) truly solve this kind of problems, then it's time to go back to study... Thanks On 1/29/2010 7:49 PM, Raoul Duke wrote: On Fri, Jan 29, 2010 at 4:24 AM, Lukas Lehner wrote: The question is, wrapping all function in try - catch does not make is clearer (from a processing point of view). Returning nil from broken functions just adds a boilerplate code all the way up. I could not find any guidelines of systematic approach of using "pure" functions in the mess of realworld. i suspect monads could be helpful here, if you go for that kind of thing. -- 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: Exception handling functional style
Hi, Am 29.01.2010 um 22:12 schrieb Lukas Lehner: > So, if they (monads) truly solve this kind of problems, then it's time to go > back to study... Maybe you also want to have a look at error-kit. Sincerely Meikel -- 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: Remote swank cannot recconnect
I'll add that into my notes and my configuration. Thanks, Kyle On Wed, Jan 27, 2010 at 4:07 AM, Lukas Lehner wrote: > Hi Kyle > > Making a new ssh tunnel is a sure thing. The bad part was that the swank > server got "deaf". I could see agents still running (unix screen is cool) > but I could not connect to is again. > As of open ports, luckily there is a firewall on the machine so only > selected ports are exposed. > > Anyway, as Anders wrote to use ":dont-close true", that actually did the > trick. > May it would be cool to update your blog post, what do you think? > > > Thanks both for replies! > Lukas > > On 1/26/2010 6:16 PM, Kyle R. Burton wrote: >>> >>> I've setup slime to remote repl according to >>> http://asymmetrical-view.com/2009/08/20/emacs-slime-remote-repl.html >>> So far so good (there are some issues, but that other time). >>> >>> There is a problem with reconnecting to the remote machine after the >>> connection is broken (running on wifi). I have tried also to telnet (at >>> the >>> remote machine) to the specified port and connection refused :( >>> >>> So I have kill the REPL every time is happens and of course I am loosing >>> all >>> the testing stuff in repl. >>> >>> Anyone having same problems? Solutions? >>> >> >> Lukas, >> >> If you've lost your network connection, you will probably need to both >> re-establish the ssh port forward (i.e. kill the ssh connection -- try >> ~ .), and run M-x slime-disconnect from your local Emacs. >> When the network connection is lost you will likely have to set up all >> the parts again - though when I've done it before swank continues to >> listen and I can re-establish the port forward and connect again. >> >> In that article I advise against making the swank listener bind to a >> port that is open to the internet, which is why I have the example off >> using ssh port forwarding. >> >> After your network connectivity returns, can you ssh into the remote >> machine again? >> >> >> Let us know how it goes. >> >> Regards, >> >> Kyle >> >> > > -- > 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 -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.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: Standard Practice for a Canned Lexer, Parser, Analyzer?
Liam writes: > Could someone educate me about what developers normally do when faced > with having to create a lexer / parser / analyzer, say for clojure? For parsing something like Clojure I would probably do it by hand, as the syntax is regular-enough that it's pretty easy to do. For parsing anything more complex or if I was trying to match a formally specified grammar [1] I'd probably use a generator. [1] http://python.org/doc/2.5.4/ref/grammar.txt > Why would people go with a canned solution, i.e. ready-made like soup > out of a can, instead of by hand? Because parsing complex languages is rather hard to get perfect. It becomes vary easy to misinterpret something or accept something which should be rejected. This can lead to strange bugs and sometimes security problems. When your parser is just a direct translation of the grammar you can be a lot more confident you got everything right. -- 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: Standard Practice for a Canned Lexer, Parser, Analyzer?
The way most parser generators work is that you can attach arbitrary pieces of code to be run at certain points during parsing. Usually you use this to build up your abstract syntax tree (AST). No information (except perhaps things like comments and whitespace if you don't need to preserve them) needs lost when you convert the source code to an AST. Usually you would also include in the AST useful metadata like the line and character positions particular expressions came from so that when displaying an error you can easily point out the location of the problem. If the language is simple enough, instead of building an AST you could directly emit byte-code (or directly do analysis) from within the parser, but doing so limits what you can do rather a lot. For example many compiler optimizations are transformations applied to the AST before code generation happens. Liam writes: > I wrote: […] sophisticated syntax based evaluation or inferences from > “cold code” [...] not node. > > This is just my personal language in referring to evaluating code from > its parse tree. In my mind, code when on the screen being edited: it > is cold. But when run through the clojure compiler: it is hot. My > understanding of programming is completely intuitive not formally > taught. I would imagine most analysis/refactoring tools work primarily on an AST. If they need to do something with the raw text they would just have the parser include enough information in the AST that they can reproduce the source exactly. Alternatively, for something fairly simple like method renaming in static language, they could just store the start and end locations in the text of every method name node. Then they search the AST looking for method names, pull out each of their start and end locations and do the appropriate replacements in the text. I don't think using a parser generator really limits you in any way unless perhaps you have really odd syntax rules [1]. Even then you could likely use a generator for most of the normal syntax and 'plug in' some custom code for just the bits that aren't statically parsable. [1] http://www.perlmonks.org/?node_id=663393 -- 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.contrib.test-contrib.test-jmx build error
Well, with sources freshly pulled from github just now, I was able to build contrib with no trace of the problem... Doing a (require 'clojure.contrib.jmx) followed by run-tests at the REPL also works. Still no idea what it was about, hoping it's gone for good. Thanks for the answers, it was reassuring to know that it wasn't a unique problem of my setup. Sincerely, Michal On 27 January 2010 19:12, Phil Hagelberg wrote: > Mike Hinchey writes: > >> On Wed, Jan 27, 2010 at 8:38 AM, Michał Marczyk >> wrote: >> >> I've been getting this unpleasant error building clojure.contrib >> recently: >> >> http://paste.lisp.org/display/94000 >> >> I wonder if there's a known issue behind it...? >> >> I've reported this problem before with openjdk, but sun's jdk works. > > I get it with both OpenJDK and Sun's JDK. The server running > build.clojure.org was also getting it on Sun's. But I couldn't reproduce > on any of my co-workers' machines. > > -Phil -- 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: Standard Practice for a Canned Lexer, Parser, Analyzer?
Roberto and Alex, thanks for your feedback. This is informative. I appreciate your perspectives & links. -- 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: update-in and get-in why no default?
2010/1/30 Rich Hickey : > Patches welcome for get-in, and my fnil. Groovy! uploaded to: https://www.assembla.com/spaces/clojure/tickets/256-get-in-optional-default-value https://www.assembla.com/spaces/clojure/tickets/257-add-fnil-for-wrapping-functions-to-handle-nil Regards, Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: return value of use, requires?
>> in the repl when i (use 'foo) vs. (use :foo) they both return nil, so >> it doesn't help me know that the former is right and the latter isn't. >> i think. would it be sensible for use to return true or something more >> positive than nil if it successfully brings in a namespace? > Ok. Ticket (and patch) welcome. Would it be better to throw an exception if nothing was specified to load instead of returning true/false... Because :foo is a keyword, making it a valid argument to use and require, but no load target is specified. I've uploaded a patch to the ticket Raoul created: https://www.assembla.com/spaces/clojure/tickets/253-Improve-errors-for--use---require--in-REPL user=> (require :foo) java.lang.Exception: Nothing specified to load (NO_SOURCE_FILE:0) user=> (use :foo) java.lang.Exception: Nothing specified to load (NO_SOURCE_FILE:0) user=> (use 'foo) java.io.FileNotFoundException: Could not locate foo__init.class or foo.clj on classpath: (NO_SOURCE_FILE:0) user=> (use 'clojure.test) nil Please clarify if this meets the desired behavior. Regards, Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
c.c.logging patches
Could someone with the necessary rights please apply the patches for contrib tickets 44 and 58. http://www.assembla.com/spaces/clojure-contrib/tickets/44 http://www.assembla.com/spaces/clojure-contrib/tickets/58 -- 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: idiom question: infinite sequence as data source for many threads?
Thank you Meikel, I was aware of the nil issue but it's good that you
made that explicit.
I got rid of the 'symbol per your suggestion, and factored the closure
to take the stream as an input:
(defn init-features [stream]
(let [feature-stream (ref stream)]
(dosync (ref-set feature-stream stream))
(fn []
(dosync
(let [f (first @feature-stream)]
(alter feature-stream rest)
f)
It's amazing to me how concise this is. I'm really loving Clojure! I
kinda miss typing 'lambda' instead of 'fn' or '#(', but I suppose a
macro can fix that. Must have been done already :)
On Jan 29, 1:42 am, Meikel Brandmeyer wrote:
> Hi,
>
> On Jan 29, 5:05 am, free_variation wrote:
>
>
>
> > You people are terrific, thanks so much.
>
> > I basically went with what Michal and Konrad worked out:
>
> > (let [feature-stream (ref nil)]
> > (defn init-features [stream]
> > (dosync (ref-set feature-stream stream))
> > 'ready)
> > (defn get-feature []
> > (dosync
> > (let [f (first @feature-stream)]
> > (alter feature-stream rest)
> > f
>
> > Works like a charm. Are the ref to nil (as initial value) and the
> > constructor-like "init-features" in the closure idiomatic to Clojure?
> > I realize I'm writing scheme here :)
>
> Please note, that you cannot distinguish a nil in the stream from an
> exhausted stream. That's the reason I returned the whole seq in my
> solution and not only the first element. Maybe this doesn't apply in
> your case, but you should keep it in mind for other occasions.
>
> For the idiomatic question (and personal taste): Use :keywords instead
> of 'quoted-symbols. I would not hard-wire the ref. I would make it
> explicit as an argument. You can spice this more general function for
> convenience with partial.
>
> Sincerely
> Meikel
--
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: Exception handling functional style
Lukas Lehner a écrit : Now, imagine the chain of calling functions is relatively big. Here it can all fall down on access-external-source causing an exception, but further up, maybe the message is scrambled, or pretty much anything. The question is, wrapping all function in try - catch does not make is clearer (from a processing point of view). Returning nil from broken functions just adds a boilerplate code all the way up. One approach you might want to look at is the maybe monad (clojure.contrib.monads/maybe-m). It takes care of (i.e. abstracts away) the boilerplate for chaining together functions that return nil to indicate failure. Konrad __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4819 (20100130) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.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: Standard Practice for a Canned Lexer, Parser, Analyzer?
On 30 January 2010 01:18, Alex Osborne wrote: > Liam writes: > >> Could someone educate me about what developers normally do when faced >> with having to create a lexer / parser / analyzer, say for clojure? > > For parsing something like Clojure I would probably do it by hand, as > the syntax is regular-enough that it's pretty easy to do. For parsing > anything more complex or if I was trying to match a formally specified > grammar [1] I'd probably use a generator. > > [1] http://python.org/doc/2.5.4/ref/grammar.txt How about for things like binary network protocols? Would you treat them the same way as e.g. source code for a language? Obviously there's no "code generation", but you still need to parse it. -- Michael Wood -- 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: idiom question: infinite sequence as data source for many threads?
Below I present 'submit-future' which is similar to the existing 'future' call in that it spawns a thread to execute a task, but differs in that it will block if n submitted futures are already running, where n is the number of available processors. I think this could be quite handy for the producer-consumer model which lazy-seq lends itself to, allowing one to write: (doseq [d data-seq] (submit-future (foo d))) where data-seq is some feed of CPU bound tasks which you want to process as quickly as possible. This is diverging from the OP, but thought it might be of interest: (let [limit (.availableProcessors (Runtime/getRuntime)) sem (java.util.concurrent.Semaphore. limit)] (defn submit-future-call "Takes a function of no args and yields a future object that will invoke the function in another thread, and will cache the result and return it on all subsequent calls to deref/@. If the computation has not yet finished, calls to deref/@ will block. If n futures have already been submitted, then submit-future blocks until the completion of another future, where n is the number of available processors." [#^Callable task] ; take a slot (or block until a slot is free) (.acquire sem) (try ; create a future that will free a slot on completion (future (try (task) (finally (.release sem (catch java.util.concurrent.RejectedExecutionException e ; no task was actually submitted (.release sem) (throw e) (defmacro submit-future "Takes a body of expressions and yields a future object that will invoke the body in another thread, and will cache the result and return it on all subsequent calls to deref/@. If the computation has not yet finished, calls to deref/@ will block. If n futures have already been submitted, then submit-future blocks until the completion of another future, where n is the number of available processors." [& body] `(submit-future-call (fn [] ~...@body))) #_(example user=> (submit-future (reduce + (range 1))) # user=> (submit-future (reduce + (range 1))) # user=> (submit-future (reduce + (range 1))) ;; blocks at this point for a 2 processor PC until the previous ;; two futures complete #) -- 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
simple-peg, sharing my experience and looking for advice, forks, patches, or anything I can get
A few days ago, I posted my unfinished rendition of a PEG parser generator on github, accessible at http://github.com/bmillare/simple-peg/ (Note, if you are looking for a working lib for parsing expression grammars (PEGs), please refer to http://www.lithinos.com/clj-peg/ ) I find writing parsers to be interesting but find writing parser generators to be quite challenging. I hope sharing my experiences will provide some value to the clojure community but ultimately I wish to complete a useful open source project so we can use it in our projects, so I am seeking feedback. If you are unfamiliar with PEGs, please check the wiki, but in a nutshell, they provide another way to describe parsers without ambiguity because of the "ordered-choice" operator instead of "or". As far as implementation goes, I took the most straightforward approach I could think of. I started by taking a look at the wikipedia definition for a PEG and defined the operators. Then, I used the idea mentioned by Xach about generating a tree of closures instead of using eval or compile. I wrote a make-parser function that takes a sequence that describes the PEG in an s- expression like format, and returns the head function of a closure tree that parses sequences according to the PEG. This has the advantage of not having to recompile unnecessarily and avoid using the slow eval operator. The PEG sequence format is defined as follows: The first item is a keyword with a name that is the same as the operator of the same name. The remaining items in the sequence are either terminal, like a character or an object, or non-terminals, which is just another PEG sequence. To make things more convenient, I defined a set of macros that generate the PEG sequence in a way that is less verbose then typing out the full name of the operator. The advantage of using this method is the sequence can be generated by other clojure code which is more flexible then describing the PEG as a string, which then has to be parsed. Although, it should be quite easy to add that functionality since we would only need a function that generates the sequences given a string. Lastly, I implemented a macro that to the user, acts like a let form but for PEGs. PEGs usually are described using a set of named non- terminals and the non-terminals can refer to other non-terminals. This is slightly more complicated than a simple let form because PEGs can have cyclic dependencies where as let forms cannot. letfn's can refer to each other freely so I wrapped the PEG sequences in functions. The user sees PEGs being binded to names but in actuality, functions are bound to names, and those names used in the PEGs are transformed into their function calls using symbol macros. To prevent stack overflows with cycles, all the functions return lazy sequences. The macro then returns the parser function that takes an input sequence and outputs either the rest of the unparsed input, or nil if it fails. Note that this means if it outputs the empty sequence, it succeeded because the empty sequence is distinct from nil. I would like to say everything works correctly but currently PEGs with cycles create slightly incorrect parsers. I can't seem to find the problem, the binding macro seems to generate the proper code. Running the make-parser on simple PEGs seems to work fine. I've decorated many of the functions with println's to help provide some debugging info. I suppose I could use some of the trace libs to make this easier. After this problem is solved, I plan on implementing a way to interleave user provided clojure code to be executed as the parser parses the input or output the AST (which I believe can be implemented as the default code to be run as the parser parses) If it sounds like I'm asking others to help me debug my code, that's because that's exactly what I'm doing. Given that this is an open source project, I don't see that being a problem. I'm trying out the "if you feel you're ready to release, you've released to late" philosophy. Best, Brent Millare -- 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
