Re: A Clojure documentation browser
On Feb 12, 3:31 pm, Craig Andera wrote:
> > Nice work!
>
> Thanks.
>
> > Two things related to 'strcat'.
>
> > 1) This is already implemented as clojure.core/str (and is more
> > efficient than concat'ing)
> > 2) This function is never called :)
>
> Yeah, that code was cut and pasted from some older work I did. It was
> removed when I started using prxml.
>
> > I have some idea's related to the presentation, but I don't have time
> > to iterate them right now.
>
> Well, pass them on whenever you get a minute. I've recently made some
> updates that are live on github [1] that may have addressed what you
> have in mind. Specifically, I've added the ability to collapse/expand
> an individual namespace or all namespaces. I've uploaded an updated
> example to the files section of this group [2].
>
> There are two more things I want to do, which probably won't be
> complete until next week:
>
> * See if I can strip the docstring from the displayed source code,
> since it's redundant.
> * Move the code into clojure.contrib, probably under the namespace
> clojure.contrib.gen-html-docs.
>
> Later, I may also have a look at making the symbols in the source code
> hyperlinks to the relevant place in the docs.
>
> [1]http://github.com/candera/doc-browse/blob/master/core.clj
> [2]http://clojure.googlegroups.com/web/clj-libs.html
Sorry for the delayed response.
I think a problem with the current layout is that once you jump to one
of the library sections you have to manually scroll back up to the
index. There are a few different ways this could be solved.
a) You could just add a "top" link to each library section banner.
b) Only show the currently selected library, and hide the rest.
c) Same as above, but also change the library navigation to a tree
view.
-> clojure.contrib.duck-streams
-) *default-encoding*
-) file
-) pwd
I did a quick implementation of B, and I think it makes the page feel
less cluttered (but I still feel it could be better). However, I did
add jQuery as a dependency. I'm not sure how 'light' you were trying
to keep this, but jQuery could simplify your JS. Here is a diff:
diff --git a/gen_html_docs.clj b/gen_html_docs.clj
index eb3616d..2e7e46b 100644
--- a/gen_html_docs.clj
+++ b/gen_html_docs.clj
@@ -129,12 +129,21 @@ function toggle(targetid, linkid, textWhenOpen,
textWhenClosed)
}
}
+$(function() {
+$('.lib-link').click(function() {
+$('.library').hide();
+var libName = 'library-' + this.text;
+$('.library[name=' + libName + ']').show();
+});
+});
+
//]]>
")
(def *style* "
.library
{
+ display: none;
padding: 0.5em 0 0 0
}
.all-libs-toggle,.library-contents-toggle
@@ -350,8 +359,7 @@ visibility of the library contents."
"Emits the HTML that documents the namespace identified by the
symbol lib."
[lib]
- [:div {:class "library"}
- [:a {:name (anchor-for-library lib)}]
+ [:div {:class "library" :name (anchor-for-library lib)}
[:div {:class "library-name"}
[:span {:class "library-contents-toggle"}
"[ "
@@ -388,7 +396,7 @@ lib, a symbol identifying that namespace."
[lib]
(let [ns (find-ns lib)]
(if ns
- [:a {:class "lib-link" :href (str "#" (anchor-for-library
lib))} (str (ns-name ns))])))
+ [:a {:class "lib-link" :href "#"} (str (ns-name ns))])))
(defn- generate-lib-links
"Generates the list of hyperlinks to each namespace, given libs, a
@@ -434,6 +442,7 @@ libraries."
[:head
[:title "Clojure documentation browser"]
[:style *style*]
+[:script {:type "text/javascript" :src "./jquery-1.3.1.js"}
[:raw! ""]]
[:script {:language "JavaScript" :type "text/javascript"} [:raw!
*script*]]
[:script {:language "JavaScript" :type "text/javascript"}
Do with my idea as you wish. I just wanted to to throw it out there.
I also think the code would be cleaner with the JS and CSS in their
own files, but I admit having everything in-lined makes it easy to
call.
Oh, almost forgot--if you do happen to try out my patch you will
notice all the links from 'miglayout.internal' on will not behave
correctly. If you look at the DOM with Firebug you'll notice that the
'miglayout' DIV is not being closed and is capturing the others. I
didn't have a chance to track down the problem, but you might want to
take a look.
-Ryan
--~--~-~--~~~---~--~~
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
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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2009, at 3:44, Rich Hickey wrote: > There will need to be good descriptions of these, but the similarity > is more in names than anything else - seqs are what they always were - > cursors, and sequences are just collections. That distinction is quite clear, the problem is indeed just in the names, in my opinion. What's the difference between a sequence and what the rest of the Lisp world calls a list? Would it be reasonable to call sequences lists? 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 15, 5:18 pm, Rich Hickey wrote: > The second option is to choose the best possible names, and deal with > some short term pain in porting and confusion. I think the best names > are: > > ;item > (first x) > > ;collection of remaining items, possibly empty > (rest x) > > ;seq on next item, or nil if none > (next x) After reading though all the information on the new, lazier sequences, I like this option best. 'next' is a very appropriate name, as it implies an eager load of the next item in the same way that first is an eager load of the first item. It also implies iteration in a way that, say, 'second' does not, so you'd also expect 'next' to have a tail. I also like way rest is now lazier. I don't think you should compromise Clojure's design at this point, so I definitely think you should go with first/rest/next. I don't like first/more/rest, as 'more' doesn't seem the best word to describe the new function, and for the same reason I also dislike first/more/next. Finally, I agree that tail/rest is also inappropriate, as tail and rest do not mean different things. So I'm all for the optimal first/rest/next solution. - James --~--~-~--~~~---~--~~ 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 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: unintended consequences of printing
Thanks for pointing this out, and glad I remember I read it. Just ran
into this 'bug'. I've a social network of agents, that can refer to
each other as either steady or casual partners (recreated a model
described in "Modeling Prevention Strategies for Gonorrhea and
Chlamydia Using Stochastic Network Simulations"). After one of the svn
revisions, looking at one of agents indeed caused a stack overflow, as
two agents are referring to each other.
user=> @(world 10)
# wrote:
> A conversation on IRC tonight[1] got me thinking... Although most
> collections can be safely printed, such as at the REPL, this is not
> true of all collections. Probably the best-known exception in Clojure
> are infinite lazy sequences, where printing can cause an infinite
> loop:
>
> (prn (iterate inc 0)) ; careful, you may not want to do this.
>
> This particular issue is addressed by the *print-level* var:
>
> user=> (binding [*print-length* 17] (prn (iterate inc 0)))
> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...)
> nil
>
> Similarly, infinitely nested seqs can cause problems:
>
> user=> (prn ((fn x [] (lazy-cons (x) nil
> java.lang.StackOverflowError (NO_SOURCE_FILE:0)
>
> Again, there's a var for this:
>
> user=> (binding [*print-level* 5] (prn ((fn x [] (lazy-cons (x) nil)
> (#)
>
> But now that atoms,agents, and refs print their contained value (as
> of svn 1254), a new kind of infinite nesting error is possible:
>
> (binding [*print-level* 4]
> (let [a (atom nil)]
> (prn (reset! a a
>
> This currently causes a StackOverflowError, but a patch and workaround
> are available[2]:
>
> #>>>
>
> But this is not the only possible problem with print deref'ing.
> Another is that it may block on the new future objects:
>
> user=> (let [f (future (Thread/sleep 3000) :done)] (prn f))
> ...three second delay...
> #
>
> I'm not sure how much of a problem this is. One option would be
> print method for future objects that doesn't deref when the future
> object is not yet done:
>
> (.addMethod print-method (class (future))
> (fn [o w]
> (.write w (format "#"
> (System/identityHashCode o)
> (if (.isDone o)
> (str ": " @o)
> " not done")
>
> user=> (def f (future (Thread/sleep 3000) 777))
> #'user/f
> user=> f
> #
>
> ...wait few seconds, then...
> user=> f
> #
>
> I'm not sure if this is worth doing or not. It's certainly not the
> only kind of trouble you can get into, printing objects. Any mutable
> Java collection can cause a problem:
>
> (let [m1 (java.util.HashMap.)
> m2 (java.util.HashMap. {:m1 m1})]
> (.put m1 :m m2)
> (prn m1))
> java.lang.StackOverflowError (NO_SOURCE_FILE:0)
>
> That's actually caused by HashMap's .toString method, so it's entirely
> outside Clojure's control.
>
> --Chouser
>
> [1]http://clojure-log.n01se.net/date/2009-02-09.html#17:53d
> [2]http://code.google.com/p/clojure/issues/detail?id=71
--~--~-~--~~~---~--~~
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
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: Fully lazy sequences are coming - feedback wanted!
Hi, Rich Hickey a écrit : > I am looking for feedback from people willing to read and understand > the linked-to documentation and the fully lazy model, and especially > from those trying the lazy branch code and porting some of your own. > I just ported Enlive (http://github.com/cgrand/enlive/commit/3245678e6ae0a82152dbf4a6fb8916d2514b60dd): * found/replaced rest by next and rrest by nnext, * no broken nil punnings (!) but several calls to seq? that could be rewritten in a less brittle way, * no metadata on sequence, is this an oversight? or is this related to the lack of metadata on closures? (I'm willing to work on this.) I'll quickly get over my imperative interpretation of 'next and I trust in your naming skills: if first/next/fine is the best option, go with it. Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 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: IntelliJ Plugin -- Wonderful News!
I see that IntelliJ has a free edition called TeamCity. Will the clojure plugin work on that IDE too? On Feb 6, 7:33 am, Peter Wolf wrote: > Check out this email! IntelliJ is going to get a *really* good plugin > for Clojure :-D > > I have gladly turned control of the my plugin over to Ilya, and the code > has been moved to the JetBrains SVN. I will remain involved and fix > bugs as they are found, but Ilya and his team are adding a real test > suite, Mac support, and implementing things like the debugger that are > not currently documented. > > I notice that Ilya has already added lots of new stuff, I am trying it now. > > There is not an release yet, but here is the new code location if you > want to build it yourself. > > http://svn.jetbrains.org/idea/Trunk/clojure-plugin > > Enjoy (Greatly) > Peter > > Hello, Peter. > > I'm going to develop plugin for IntelliJ IDEA for Clojure language. > Talking with Rich I knew about your plugin, which already has parser > and several nice features, based on it withou Program Structure > Interface. To not duplicate code I would like to suggest you to move > your source into JetBrains source repository and continue working on > plugin together. Of course, Clojure plugin will stay open-source > project. Moreover we already have off-the shelf process to build > such projects and perform continuous integartion using our > buildserver TeamCity. > As you might know, I was developing Groovy plugin (wich you took as > a base for your) for two years and now I lead development of Scala > plugin. Main feature of all of them is full interoperability with > main Java support, so I would like to keep it for Clojure too. > So, what do you think about this cooperation? If you agree I'll > submit existing code to our repository and provide commit rights for > you. > > With best regards, > Ilya --~--~-~--~~~---~--~~ 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 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: Example of use of Atom: Fibonacci generator
Also consider (from http://en.wikibooks.org/wiki/Clojure_Programming/Examples): (defn fib-seq [] ((fn rfib [a b] (lazy-cons a (rfib b (+ a b 0 1)) user> (take 20 (fib-seq)) (0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181) 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 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: Concurrency and file writing
I think it depends on whether this is CPU or IO bound, where the files will be stored and how expensive it is to generate blocks, check for existence, copy etc. Over a distributed filesystem running across data-centers the decision will probably be different than on a multi-core cpu on a single RAID box. I would guess that the scratch file method is the simplest. The problem is that you could have multiple processes creating the same temp file at the same time without some coordination, which might not be a big deal if it's a cheap operation. Otherwise, you could use the filesystem to coordinate, like writing an empty file with the hash name ahead of time to effectively take the lock before appending actual data, or you could use a data structure that keeps a record of previously written blocks or currently active blocks. If you are over a network you either have to do that coordination over sockets, or use the distributed filesystem to do it for you. Another option is the posix flock, but I don't have experience with it. It might not work for your situation, but what I was initially thinking was to abstract access to the hashed blocks and use a work queue for writing. The queue would automatically throw out duplicate blocks, and you could tune the number of parallel writer threads to maximize throughput. If you want to distribute the load you can distribute workers that are pulling jobs off the queue. Depending on whether you want readers to block or to return empty handed when requesting a block that isn't finished writing yet, you could use something like the watchers for agents to notify them when a block is ready or just return. Also, depending on your consistency and isolation requirements, the reader interface could query the write-queue to get access to blocks that haven't even been written to disk yet. In that way it could sort of act as a persistent cache. -Jeff James Reeves wrote: > Hi folks, > > I've been having some difficulty coming up with a scheme for writing > to files in a thread-safe manner. The files are named with the hash of > their content, so they are effectively immutable. > > The problem comes with writing them for the first time. I need to > ensure that while a file is initially being written, no other thread > attempts to read or write to the file. > > The best solution I've come up with so far is to write to a temporary > file, then rename the file to its hash once it has been closed. This > seems to work, but I'd be very interested to know how other people > have handled similar concurrent I/O problems in Clojure. > > - James > > > --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 1:44 pm, Rich Hickey wrote: > > My thoughts so far: > > > 4. The new model is definitely more complicated to understand than > > the previous model. There was already a certain degree of mental > > overlap between collections and the seq interface. Now, there is also > > the subtle distinction between a seq and a sequence. > > There will need to be good descriptions of these, but the similarity > is more in names than anything else - seqs are what they always > were - cursors, and sequences are just collections. Would it therefore make sense to call them cursors and collections instead of seqs and sequences? Gavin --~--~-~--~~~---~--~~ 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 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: Example of use of Atom: Fibonacci generator
Thanks for these interesting replies - I have some way to go in my understanding of the power of functional programming. I look forward to seeing Stuart's chapter 5! On Feb 16, 11:25 am, Timothy Pratley wrote: > Also consider (fromhttp://en.wikibooks.org/wiki/Clojure_Programming/Examples): > > (defn fib-seq [] > ((fn rfib [a b] > (lazy-cons a (rfib b (+ a b > 0 1)) > > user> (take 20 (fib-seq)) > (0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181) > > 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 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: error-kit + test-is
On Mon, Feb 16, 2009 at 1:50 AM, David Nolen wrote:
>
>> I don't quite understand why you got through all that work to get
>> error-str -- isn't it just (str (qualify-sym error-type))?
>>
>> ...and since you then use it only as an arg to 'symbol' or 'str', you
>> could just use the symbol itself instead of converting it to a string
>> and back.
>
> If I bring the symbol back directly, it gets evaluated to the actual error
> object and not the symbol. I want to compare symbols. Or maybe I don't,
> comparing symbols in general seems simpler for meta-hacky stuff like this.
Ah, I see the problem. You needed a string so that your expansion
could include, for example:
(symbol "clojure.contrib.error-kit/*error*")
But another way to get that result is for the expansion to instead
include:
'clojure.contrib.error-kit/*error*
I think you'll find this does exactly the same thing as yours. Note
the '~error-name:
(defmethod assert-expr 'raised? [msg [_ error-type & body :as form]]
(let [error-name (qualify-sym error-type)]
`(with-handler
(do
~...@body
(report :fail ~msg '~form ~(str error-name " not raised.")))
(handle ~error-type {:as err#}
(if (= (:tag err#) '~error-name)
(report :pass ~msg '~form nil)
(report :fail ~msg '~form ~(str error-name " was raised."
(handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))
hm, I think the second :fail message there may not be right.
--Chouser
--~--~-~--~~~---~--~~
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
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: unintended consequences of printing
On Mon, Feb 16, 2009 at 4:30 AM, bOR_ wrote: > > (remove-method print-method clojure.lang.IDeref) works like a charm, > but > > (binding [*print-level* 1] >@(world 1)) > > doesn't seem to have the desired effect. Not sure why not. Entering that at the REPL will change the value of *print-level* while you dereference, but no printing is being done then. After the value is returned to outside the binding form (and therefore the value of *print-level* has been restored to whatever it was before), that's when the REPL print the value. So at a REPL you may want to make a more lasting change by doing: (set! *print-level* 10) ; or something like that. Note that this new value of *print-level* is seen only by the thread your REPL is currently running in. --Chouser --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
I'm all for breaking bad habits and names and I love it that you give good design considerations precedence over heritage, but here I think using the first/rest/next combo is confusing, and will continue to be confusing in the long-term. rest is expected to be a sequence by Lispers, and next is expected to be an item by Java-ers. Both are universally recognized as such and are frequently used. The semantics given to them by their common use in computing (and especially in CS education) supersedes their semantics in daily English or the semantics which should have been most appropriate to them if their semantics were defined today first. Synonyms are also not a problem as they receive their unique semantics soon enough if they are regularly used, and if they're not then there is no need to waste of good short word on them. I'm against more because it evokes the semantics of the more? predicate but maybe first/ remaining/rest or instead of remaining: rest-collection, rest-coll, or restc. I seem to be in the minority about this... On Feb 15, 7:18 pm, Rich Hickey wrote: > I'm pretty much finished with the fully-lazy implementation and am > happy so far with the results. I think this will be an important > addition to Clojure and am planning to add it. > > Now comes the hard part - names and change. The essence of the fully > lazy seqs is that they will not consume any resources, perform any > computation or trigger any side effects until they are consumed. This > is a change to the way the sequence functions work now, in that, in > order to determine whether they should return a seq or nil, they need > to touch at least one item. So, there will be an additional function > on seqs, one that returns the items other than the first as a logical, > non-nil, possibly empty collection. Calling seq on this collection > will give you what rest currently gives you - the next seq object or > nil if none. So the core operations on seqs will be: > > ;item > (first x) > > ;collection of remaining items, possibly empty > (possibly-empty-collection-of-the-remaining-items x) > > ;seq on next item, or nil if none > (seq-on-the-next-item-if-any-else-nil x) > > (first x) is uncontroversial and won't change. The second is a new > function. The third is currently called 'rest'. > > I have some ideas for names, and there are definitely tradeoffs > between short-term pain and long-term goodness in some of the options. > The first option is to leave rest alone, and give the new function a > new name, like more. > > ;item > (first x) > > ;collection of remaining items, possibly empty > (more x) > > ;seq on next item, or nil if none > (rest x) > > Note that (rest x) === (seq (more x)) > > This is implemented in the lazy branch, SVN rev 1281. It has the > attribute of requiring the fewest changes to existing code, and the > drawback of leaving us with less-than-ideal names, especially insofar > as more (or whatever you choose to call it) will in some way seem > synonymous with rest. This naming scheme, and the changes it implies, > is documented here: > > http://clojure.org/lazier1 > > The second option is to choose the best possible names, and deal with > some short term pain in porting and confusion. I think the best names > are: > > ;item > (first x) > > ;collection of remaining items, possibly empty > (rest x) > > ;seq on next item, or nil if none > (next x) > > This is implemented in the lazy branch, SVN rev 1282. Note that this > changes the meaning of rest, and gives the current rest operation a > new name, next. It has the attributes of using the most appropriate > names (IMO) and the drawback of changing the semantics of a frequently > used function name, but still offering that functionality under a > different name. It would also break the compatibility of rest with > Common Lisp's. As with the previous model, the third function can be > defined in terms of the second - (next x) === (seq (rest x)). This > naming scheme, and the changes it implies, is documented here: > > http://clojure.org/lazier > > A third option would be to retire rest and use only new names: > > ;item > (first x) > > ;collection of remaining items, possibly empty > (more x) > > ;seq on next item, or nil if none > (next x) > > I haven't implemented this. > > I prefer first/rest/next. I think rest is the best complement to > first, and it should mean the logical collection once things are fully > lazy. I think next implies the next seq, as well as the eager nature > of the operation. > > I am looking for feedback from people willing to read and understand > the linked-to documentation and the fully lazy model, and especially > from those trying the lazy branch code and porting some of your own. > Questions on the model welcome as well. Chouser has also blogged a bit > about this, with some useful descriptions of nil punning: > > http://blog.n01se.net/?p=39 > > I've been working on this for a few months, in lieu of more > interesting things, because I
Re: Fully lazy sequences are coming - feedback wanted!
I'd vote for the breaking changes. We don't have so much code written that it cannot be fixed. However, this depends on the book in production. Having _Programming Clojure_ come out with incompatible code would be a big blow, I think. On Mon, Feb 16, 2009 at 9:22 AM, Mibu wrote: > > I'm all for breaking bad habits and names and I love it that you give > good design considerations precedence over heritage, but here I think > using the first/rest/next combo is confusing, and will continue to be > confusing in the long-term. > > rest is expected to be a sequence by Lispers, and next is expected to > be an item by Java-ers. Both are universally recognized as such and > are frequently used. The semantics given to them by their common use > in computing (and especially in CS education) supersedes their > semantics in daily English or the semantics which should have been > most appropriate to them if their semantics were defined today first. > > Synonyms are also not a problem as they receive their unique semantics > soon enough if they are regularly used, and if they're not then there > is no need to waste of good short word on them. I'm against more > because it evokes the semantics of the more? predicate but maybe first/ > remaining/rest or instead of remaining: rest-collection, rest-coll, or > restc. > > I seem to be in the minority about this... > > > On Feb 15, 7:18 pm, Rich Hickey wrote: > > I'm pretty much finished with the fully-lazy implementation and am > > happy so far with the results. I think this will be an important > > addition to Clojure and am planning to add it. > > > > Now comes the hard part - names and change. The essence of the fully > > lazy seqs is that they will not consume any resources, perform any > > computation or trigger any side effects until they are consumed. This > > is a change to the way the sequence functions work now, in that, in > > order to determine whether they should return a seq or nil, they need > > to touch at least one item. So, there will be an additional function > > on seqs, one that returns the items other than the first as a logical, > > non-nil, possibly empty collection. Calling seq on this collection > > will give you what rest currently gives you - the next seq object or > > nil if none. So the core operations on seqs will be: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (possibly-empty-collection-of-the-remaining-items x) > > > > ;seq on next item, or nil if none > > (seq-on-the-next-item-if-any-else-nil x) > > > > (first x) is uncontroversial and won't change. The second is a new > > function. The third is currently called 'rest'. > > > > I have some ideas for names, and there are definitely tradeoffs > > between short-term pain and long-term goodness in some of the options. > > The first option is to leave rest alone, and give the new function a > > new name, like more. > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (more x) > > > > ;seq on next item, or nil if none > > (rest x) > > > > Note that (rest x) === (seq (more x)) > > > > This is implemented in the lazy branch, SVN rev 1281. It has the > > attribute of requiring the fewest changes to existing code, and the > > drawback of leaving us with less-than-ideal names, especially insofar > > as more (or whatever you choose to call it) will in some way seem > > synonymous with rest. This naming scheme, and the changes it implies, > > is documented here: > > > > http://clojure.org/lazier1 > > > > The second option is to choose the best possible names, and deal with > > some short term pain in porting and confusion. I think the best names > > are: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (rest x) > > > > ;seq on next item, or nil if none > > (next x) > > > > This is implemented in the lazy branch, SVN rev 1282. Note that this > > changes the meaning of rest, and gives the current rest operation a > > new name, next. It has the attributes of using the most appropriate > > names (IMO) and the drawback of changing the semantics of a frequently > > used function name, but still offering that functionality under a > > different name. It would also break the compatibility of rest with > > Common Lisp's. As with the previous model, the third function can be > > defined in terms of the second - (next x) === (seq (rest x)). This > > naming scheme, and the changes it implies, is documented here: > > > > http://clojure.org/lazier > > > > A third option would be to retire rest and use only new names: > > > > ;item > > (first x) > > > > ;collection of remaining items, possibly empty > > (more x) > > > > ;seq on next item, or nil if none > > (next x) > > > > I haven't implemented this. > > > > I prefer first/rest/next. I think rest is the best complement to > > first, and it should mean the logical collection once things are fully > > lazy. I think next implies the next seq, as well as
Re: Fully lazy sequences are coming - feedback wanted!
While I'm fairly new to clojure, and with apologies to Stewart Halloway for complicating his job on the book, (which is excellent so far, btw) I think it would be worth while to chose the optimum naming convention, if it can be done fast enough to update the book. Consider how long some warts had been around before Python 3 removed them, we're going to have to deal with these things for a long time... That said, having the book fall out of compliance with clojure would be REALLY bad. I had that experience with "The Definitive Guide to Django", which wasn't, and it really turned me off. (The fact that people made snarky comments on IRC when I asked why things didn't work didn't help either; after a change like this you can't just tell people to RTFM.) ~Jason --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Clojure's version display
Hi, There is a way to display the current clojure's version ? Something like java -cp $CLOJURE_JAR:$CLOJURE_CONTRIB_JAR clojure.main -v Thanks. Alin --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
If we're going to be making name changes that break code anyway, I'll make another appeal to make the function naming convention more consistent. Most multi-word function names have a hyphen between the words, but the following do not. butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym, macroexpand, macroexpand-1, mapcat, nthrest If we want to keep these names as-is then why do we have hyphens in so many of the other multi-word function names? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
compiling a GUI app and also: interference of Java's built-in architechture
Hi, I know that all Java GUI libraries can be used within the REPL, but it is my understanding that in order to make it self-contained and executable (a jar or a class file), it is necessary to write some Java and call the Clojure code from the java applet or application. Is this true, or am I doing it wrong? I know a lot more about Common Lisp than I know about Java by the way, so I end up having to figure out Java stuff sometimes in order to do certain things in Clojure... Another question I have has to do with the applet model and mutable state. It seems like an applet's required architecture forces you to do things less idiomatically and make use of globally defined agents or refs that change. To give an example from the applet I am writing (but this is general across almost all applets I would think), the paint function in Clojure (called by the paint method of the java applet) receives a graphics object. Meanwhile the mouseDown function receives the coordinates of the pointing device, does something, and calls repaint. Mousedown function therefore is expected to modify some globally defined state so that repaint can use it in repainting. Would I be wrong to assume that this forces a Clojure-unfriendly structure onto the Clojure applet? So if I am right about these two facts, it seems like Clojure should include a native way of making applets/applications that both enables the truly functional style that Clojure is built on, and doesn't require writing Java to call it (it seems like Clojure should replace Java, not perpetuate it, other than to build on its vast libraries, IMHO). What do you think (and is there something I'm understanding wrong here)? Rob --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Mon, Feb 16, 2009 at 10:10 AM, Mark Volkmann wrote: > > If we're going to be making name changes that break code anyway, I'll > make another appeal to make the function naming convention more > consistent. Most multi-word function names have a hyphen between the > words, but the following do not. > > butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym, > macroexpand, macroexpand-1, mapcat, nthrest > > If we want to keep these names as-is then why do we have hyphens in so > many of the other multi-word function names? > > +1 And ideally real soon so Stuart can change that at the same time as adding the fully lazy changes. --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
> > I know that all Java GUI libraries can be used within the REPL, but it is > my understanding that in order to make it self-contained and executable (a > jar or a class file), it is necessary to write some Java and call the > Clojure code from the java applet or application. Is this true, or am I > doing it wrong? > > I know a lot more about Common Lisp than I know about Java by the way, so I > end up having to figure out Java stuff sometimes in order to do certain > things in Clojure... > Java's Swing is terrible and if possible, you should avoid it. If you have to do an applet then you might not have a choice but if you can use Java Web Start, go with Jambi. Jambi is a binding for the much cleaner and friendly Qt toolkit. You can see it in action (java web start so no installing required) here: http://dist.trolltech.com/developer/download/webstart/index.html You would also benefit from an awesome interface designer (which is *not* an IDE so you can do your GUI in it and code with your favourite editor). The drawback (beside not being able to do applets) is that there is a different jar file you have to bundle for each platform (but they all have the same api so it's really just a packaging concern). In the past, there would also be a potential licensing problem (either GPL your code or pay up) but the next release (next month) will be LGPLed so you can do a proprietary app with it if you wish. --~--~-~--~~~---~--~~ 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 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's version display
On Feb 16, 2009, at 3:39 AM, Alin Popa wrote:
Hi,
There is a way to display the current clojure's version ?
Something like java -cp $CLOJURE_JAR:$CLOJURE_CONTRIB_JAR
clojure.main -v
Thanks.
Alin
I think if a Clojure version identifier existed, that would be a good
way to print it. I support an issue to request that when version info
exists, it be made available through a "-v" or "--version" argument on
clojure.main.
Currently, there is no clean way to provide a Clojure version number.
Some ways based on SVN revision have been proposed, but my impression
is that there hasn't been consensus that it would be something that
could be ensured to be correct automatically enough to be useful.
Sometime there will be Clojure releases with version numbers. At that
time, it seems most natural to me for version info to be available via
a global variable like "*clojure-version*" whose value might be a
small map like {:release true :major 1 :minor 0 :revision 0 :date
"20090101T"} for release builds and {:release false :date
20090204T093247} for unofficial builds.
No such mechanism is yet available.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
Re: compiling a GUI app and also: interference of Java's built-in architechture
> I know that all Java GUI libraries can be used within the REPL, but it is my > understanding that in order to make it self-contained and executable (a jar > or a class file), it is necessary to write some Java and call the Clojure > code from the java applet or application. Is this true, or am I doing it > wrong? If you have a Clojure namespace that uses gen-class, and if there is a method called '-main' within that namespace, then the resultant *.class file is equivalent to a Java class with a 'main' method, and you can invoke it in the same way. See http://clojure.org/compilation for an example. > Another question I have has to do with the applet model and mutable state. > It seems like an applet's required architecture forces you to do things less > idiomatically and make use of globally defined agents or refs that change. > To give an example from the applet I am writing (but this is general across > almost all applets I would think), the paint function in Clojure (called by > the paint method of the java applet) receives a graphics object. Meanwhile > the mouseDown function receives the coordinates of the pointing device, does > something, and calls repaint. Mousedown function therefore is expected to > modify some globally defined state so that repaint can use it in > repainting. Would I be wrong to assume that this forces a > Clojure-unfriendly structure onto the Clojure applet? > > So if I am right about these two facts, it seems like Clojure should include > a native way of making applets/applications that both enables the truly > functional style that Clojure is built on, and doesn't require writing Java > to call it (it seems like Clojure should replace Java, not perpetuate it, > other than to build on its vast libraries, IMHO). What do you think (and is > there something I'm understanding wrong here)? Maybe I'm misunderstanding what you're asking, but isn't this an inherently stateful scenario? IO is always stateful, and the concept of "painting", whenever I use it, is to render the current application state to the screen. For example, I'm writing a word processor in Clojure and QT. My paint function, quite simply, takes the current state of the document and renders it to the screen. My input functions, on the other hand, modify the state of the document and then send an asynchronous notification that the document state has changed. I find this to be a quite logical breakdown of responsibilities. Sure, its not purely functional, but again, IO can never be. Also, keep in mind that although Clojure data structures are purely functional and immutable, when you're doing a GUI you're dealing with Swing Java objects which keep around quite a lot of state. But it still works quite nicely in Clojure. Clojure provides a very nice mix of purity and practicality. All my functions for logic and data manipulation are pure, but it is no trouble to reach out and mutate state (in my case, Java Objects) when I need to. I can be quite explicit about what I'm doing, and isolate my side effects in a very controlled way. Hope that helps, -Luke --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
> butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym, > macroexpand, macroexpand-1, mapcat, nthrest > > -1 Because they are similar to other Lisps I assume. The same reason for println vs print-line. Changing these are a bad idea in IMHO. Breaking the meaning of rest with Common Lisp is a consideration to take seriously. However as long as the documentation clearly states (highlights in big bold colors ;) this difference (and the fact the operation is support by next) then I think this is a change people can live with. --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2009, at 11:25 AM, David Nolen wrote: > > butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym, > macroexpand, macroexpand-1, mapcat, nthrest > > > -1 > > Because they are similar to other Lisps I assume. The same reason > for println vs print-line. Changing these are a bad idea in IMHO. > > Breaking the meaning of rest with Common Lisp is a consideration to > take seriously. However as long as the documentation clearly states > (highlights in big bold colors ;) this difference (and the fact the > operation is support by next) then I think this is a change people > can live with. Changing these names is not on the table. 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 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: compiling a GUI app and also: interference of Java's built-in architechture
I agree, Jambi is a better all-round product... but why the Swing hate? It's fine for what it is. Most of it's drawbacks (horrible L&F, poor performance) are things of the past, now. It would definitely be my framework of choice for a quick, one-off app or an applet. -Luke On Feb 16, 10:50 am, Dan wrote: > > I know that all Java GUI libraries can be used within the REPL, but it is > > my understanding that in order to make it self-contained and executable (a > > jar or a class file), it is necessary to write some Java and call the > > Clojure code from the java applet or application. Is this true, or am I > > doing it wrong? > > > I know a lot more about Common Lisp than I know about Java by the way, so I > > end up having to figure out Java stuff sometimes in order to do certain > > things in Clojure... > > Java's Swing is terrible and if possible, you should avoid it. If you have > to do an applet then you might not have a choice but if you can use Java Web > Start, go with Jambi. > > Jambi is a binding for the much cleaner and friendly Qt toolkit. You can see > it in action (java web start so no installing required) > here:http://dist.trolltech.com/developer/download/webstart/index.html > > You would also benefit from an awesome interface designer (which is *not* an > IDE so you can do your GUI in it and code with your favourite editor). > > The drawback (beside not being able to do applets) is that there is a > different jar file you have to bundle for each platform (but they all have > the same api so it's really just a packaging concern). In the past, there > would also be a potential licensing problem (either GPL your code or pay up) > but the next release (next month) will be LGPLed so you can do a proprietary > app with it if you wish. --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
Regarding Programming Clojure: I think that placing the burden of "book vs actual" incompatibility upon Rich is misplaced. If anything, pressure from the Clojure community should be placed on the Pragmatic Programmers to allow Stuart to "do the right thing" regarding when the book is released, viz., when Clojure has stabilized. Realize who is making the open contribution and who is profiting from that contribution and keep the priorities straight. My 2 cents. Walt --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
On Mon, Feb 16, 2009 at 10:27 AM, rob levy wrote: > So if I am right about these two facts, it seems like Clojure should > include a native way of making applets/applications that both enables the > truly functional style that Clojure is built on, and doesn't require writing > Java to call it (it seems like Clojure should replace Java, not perpetuate > it, other than to build on its vast libraries, IMHO). What do you think > (and is there something I'm understanding wrong here)? > Someone correct me if I'm way off, but User Interfaces are by definition very mutation heavy. It has come up before that Clojure's emphasis on immutability is a tool not a religious decree. Mutation is fine, just don't mindlessly sprinkle it all over your program. Even a language like Haskell (which I know very little about) needs special constructs for IO. But this is exactly what your example illustrates! mouse -> I, screen -> O. Mutability sneaks in ;) Of course it would be interesting to see a UI framework that is more functional, but having done a considerable amount of UI programming this seems to me like mostly a waste of time. Instead of dictating, Clojure simply encourages you to reflect on whether you really need mutation. If you absolutely need mutation, Clojure isn't going to stop you. And that's a great thing. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: compiling a GUI app and also: interference of Java's built-in architechture
On Mon, Feb 16, 2009 at 11:33 AM, levand wrote: > > I agree, Jambi is a better all-round product... but why the Swing > hate? It's fine for what it is. Most of it's drawbacks (horrible L&F, > poor performance) are things of the past, now. > > It would definitely be my framework of choice for a quick, one-off app > or an applet. > > -Luke My experience working with Swing have mostly been painful and my experience working with Qt (mostly PyQt) have been much more pleasurable. I don't hate Swing, it's just very awkward by comparison. And there is still one major drawback: having a good GUI builder (nothing compares to Qt Designer yet) that does not tie you into a particular IDE (sucks for collaboration). I'm not saying that Swing should not be used, just that Jambi should be prefered. --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
Also, don't forget that Jambi is a vanilla GPL 2.0, so make sure all your licenses are compatible and you don't mind publishing your source (personally I don't, but you should be aware). Tom 2009/2/16 levand > > I agree, Jambi is a better all-round product... but why the Swing > hate? It's fine for what it is. Most of it's drawbacks (horrible L&F, > poor performance) are things of the past, now. > > It would definitely be my framework of choice for a quick, one-off app > or an applet. > > -Luke > > On Feb 16, 10:50 am, Dan wrote: > > > I know that all Java GUI libraries can be used within the REPL, but it > is > > > my understanding that in order to make it self-contained and executable > (a > > > jar or a class file), it is necessary to write some Java and call the > > > Clojure code from the java applet or application. Is this true, or am > I > > > doing it wrong? > > > > > I know a lot more about Common Lisp than I know about Java by the way, > so I > > > end up having to figure out Java stuff sometimes in order to do certain > > > things in Clojure... > > > > Java's Swing is terrible and if possible, you should avoid it. If you > have > > to do an applet then you might not have a choice but if you can use Java > Web > > Start, go with Jambi. > > > > Jambi is a binding for the much cleaner and friendly Qt toolkit. You can > see > > it in action (java web start so no installing required) here: > http://dist.trolltech.com/developer/download/webstart/index.html > > > > You would also benefit from an awesome interface designer (which is *not* > an > > IDE so you can do your GUI in it and code with your favourite editor). > > > > The drawback (beside not being able to do applets) is that there is a > > different jar file you have to bundle for each platform (but they all > have > > the same api so it's really just a packaging concern). In the past, there > > would also be a potential licensing problem (either GPL your code or pay > up) > > but the next release (next month) will be LGPLed so you can do a > proprietary > > app with it if you wish. > > > --~--~-~--~~~---~--~~ 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 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: IntelliJ Plugin -- Wonderful News!
Team City is not an IDE, it is a continuous integration server. I think Jetbrains give it away to Intellij licensees. Tom 2009/2/16 Johan Berntsson > > I see that IntelliJ has a free edition called TeamCity. Will the > clojure plugin work on that IDE too? > > On Feb 6, 7:33 am, Peter Wolf wrote: > > Check out this email! IntelliJ is going to get a *really* good plugin > > for Clojure :-D > > > > I have gladly turned control of the my plugin over to Ilya, and the code > > has been moved to the JetBrains SVN. I will remain involved and fix > > bugs as they are found, but Ilya and his team are adding a real test > > suite, Mac support, and implementing things like the debugger that are > > not currently documented. > > > > I notice that Ilya has already added lots of new stuff, I am trying it > now. > > > > There is not an release yet, but here is the new code location if you > > want to build it yourself. > > > > http://svn.jetbrains.org/idea/Trunk/clojure-plugin > > > > Enjoy (Greatly) > > Peter > > > > Hello, Peter. > > > > I'm going to develop plugin for IntelliJ IDEA for Clojure language. > > Talking with Rich I knew about your plugin, which already has parser > > and several nice features, based on it withou Program Structure > > Interface. To not duplicate code I would like to suggest you to move > > your source into JetBrains source repository and continue working on > > plugin together. Of course, Clojure plugin will stay open-source > > project. Moreover we already have off-the shelf process to build > > such projects and perform continuous integartion using our > > buildserver TeamCity. > > As you might know, I was developing Groovy plugin (wich you took as > > a base for your) for two years and now I lead development of Scala > > plugin. Main feature of all of them is full interoperability with > > main Java support, so I would like to keep it for Clojure too. > > So, what do you think about this cooperation? If you agree I'll > > submit existing code to our repository and provide commit rights for > > you. > > > > With best regards, > > Ilya > > > --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
On Mon, Feb 16, 2009 at 11:51 AM, Tom Ayerst wrote: > Also, don't forget that Jambi is a vanilla GPL 2.0, so make sure all your > licenses are compatible and you don't mind publishing your source > (personally I don't, but you should be aware). > > Tom > Only until Qt 4.5 which is due in march 2009. From then, the license will be LGPL. --~--~-~--~~~---~--~~ 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 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: cljc?
> > Meikel, Could explain your code such that somebody like me could understand it and even play with it? Regards, Emeka --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
I agree with the majority of posters that the breaking changes in the
service of optimal names is the right way to go.
I found the explanation & recipe for porting at clojure.org/lazier
clear & easy to follow. I didn't do full ports of any projects, but I
did some selective porting & found it to be straightforward.
That said, the only problem I see is with the names. Like Mibu, I
think "next" isn't ideal -- it connotes an item in an iteration to me.
If you think "next *seq*" when you see "next" (how Rich explains it
at /lazier), it helps, but it's still not exactly right; or it
requires a different mental model from the non-lazy-branch "rest": the
cursor moving to the "next" item rather than the abstracted "rest of
the coll" (where you think about a cursor).
I think the issue is that "rest" is the right name for both rest &
next. The only difference between them, from the perspective of users,
is how empty rests are represented ('() or nil), & that's a hard
distinction to make manifest in a short name.
If it's the case that rest will almost exclusively appear in the
context of constructing lazy-seqs
(lazy-seq
(cons [something] (rest [something]))
& next will appear all over, it makes sense to me to sacrifice brevity
in the case of rest, & give next the right name: "rest" (that's
tortuous, I know).
rest* isn't quite right, but you get the idea: make the fully-lazy
rest the special-kind-of-rest, & the consumer-code rest the
transparent one. This way, people's concepts about recursing through
seqs of colls & testing for the end won't have to change; they'll only
have to change their understanding of how to make lazy sequences. I
know in my code I do a lot more of the former.
Anyone who's on board with this line of thought have ideas for the
right name of fully-lazy rest?
Best,
Perry
--~--~-~--~~~---~--~~
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
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: Fully lazy sequences are coming - feedback wanted!
You're right, of course, but in life compromises must happen. If Rich proceeds *with no regard* for Pragmatic's needs, they have a recourse which is simply no Clojure book. Or a Clojure book that has broken examples. On Mon, Feb 16, 2009 at 11:34 AM, wlr wrote: > > Regarding Programming Clojure: > > I think that placing the burden of "book vs actual" incompatibility > upon Rich is misplaced. If anything, pressure from the Clojure > community should be placed on the Pragmatic Programmers to allow > Stuart to "do the right thing" regarding when the book is released, > viz., when Clojure has stabilized. > > Realize who is making the open contribution and who is profiting from > that contribution and keep the priorities straight. > > My 2 cents. > > Walt > > > --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
> cursor moving to the "next" item rather than the abstracted "rest of > the coll" (where you think about a cursor). Correction: where you *don't* think about a cursor... Perry --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
2009/2/16 Dan > > > On Mon, Feb 16, 2009 at 11:33 AM, levand wrote: > >> >> I agree, Jambi is a better all-round product... but why the Swing >> hate? It's fine for what it is. Most of it's drawbacks (horrible L&F, >> poor performance) are things of the past, now. >> >> It would definitely be my framework of choice for a quick, one-off app >> or an applet. >> >> -Luke > > > My experience working with Swing have mostly been painful and my experience > working with Qt (mostly PyQt) have been much more pleasurable. I don't hate > Swing, it's just very awkward by comparison. Hello, Do you know of a good pointer that goes beyond the "don't use it" argument, and really makes a thorough comparison of pros and cons of the 2 frameworks ? > > > And there is still one major drawback: having a good GUI builder (nothing > compares to Qt Designer yet) that does not tie you into a particular IDE > (sucks for collaboration). > > I'm not saying that Swing should not be used, just that Jambi should be > prefered. > > > > > > > --~--~-~--~~~---~--~~ 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 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: error-kit + test-is
(defmethod assert-expr 'raised? [msg [_ error-type & body :as form]]
(let [error-name (qualify-sym error-type)]
`(with-handler
(do
~...@body
(report :fail ~msg '~form ~(str error-name " not raised.")))
(handle ~error-type {:as err#}
(report :pass ~msg '~form nil))
(handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))
You're right I think the entire first handle statement was wrong. I believe
handle does the isa? check on the error type, correct? If so then this will
allow inherited error types to pass the test.
Many, many thanks for the feedback.
test-is + error-kit is a great combo.
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
New lazy branch of clojure-contrib
I created a lazy branch of clojure-contrib to track patches to contrib that are needed in the lazy branch of Clojure. For clojure-contrib hackers: svn checkout https://clojure-contrib.googlecode.com/svn/branches/lazy clojure-contrib-lazy --username your.google.account For everyone else: svn checkout http://clojure-contrib.googlecode.com/svn/trunk/ clojure- contrib-lazy -Stuart Sierra --~--~-~--~~~---~--~~ 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 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: error-kit + test-is
On Mon, Feb 16, 2009 at 12:13 PM, David Nolen wrote: > > I believe handle does the isa? check on the error type, correct? Right. > If so then this will allow inherited error types to pass the test. Sounds good! --Chouser --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 12:06 pm, Jeffrey Straszheim wrote: > You're right, of course, but in life compromises must happen. If Rich > proceeds *with no regard* for Pragmatic's needs, they have a recourse which > is simply no Clojure book. Or a Clojure book that has broken examples. > Agreed. I'm afraid my original came out sounding more militant than what I intended. It was really a reaction to some posts which correctly suggested that Clojure would suffer by being touted by an out-of-synch Programming Clojure but also failed to suggest compromise on Pragmatic's side of the equation. The tone seemed to be permissive of Pragmatic proceeding *with no regard* for Clojure's current and soon-to-be reality. I don't believe that folks who have already forked over money for the book would be out of line in suggesting to Pragmatic that they adjust the publication schedule. Neither would inquiries from prospective buyers as to Pragmatic's intentions regarding book vs actual faithfulness. I didn't mean to suggest an all-out, mean-spirited attack but can see how that inference could easily have been drawn. Walt --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Anonymous recursive functions
I just discovered a nice feature that I don't remember having seen discussed or documented before: there is a way to write recursive functions without having them associated to any var/symbol in any namespace. The optional name of a function can be used for a recursive call. Example: ((fn fac [n] (if (zero? n) 1 (* n (fac (dec n) 5) I know this is not the best way to write a factorial (it is not tail- recursive), the point is just to show an example of a recursive call. 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 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: compiling a GUI app and also: interference of Java's built-in architechture
> Hello, > > Do you know of a good pointer that goes beyond the "don't use it" argument, > and really makes a thorough comparison of pros and cons of the 2 frameworks > ? > I'm not saying don't use Swing, I'm saying prefer Jambi. My memory of Swing is dated so I'd have trouble making a thorough comparison but I can provide an outline. In favour of Swing: - No extra dependencies - No license restriction (Qt 4.4 requires you to buy a commercial license if you don't want to opensource your app, won't be true anymore with Qt 4.5) - De facto standard - Instantly cross-platform (Jambi requires you to package a different jar for each platform) In favour of Qt: - Great GUI builder (optional of course but you should give it a try, it's powerful and doesn't get in your way) - Cross-language (you can easily use the same GUI in C++, Python, Java, Ruby, Perl, and a few others with minimal porting efforts - Signals and slots, great way to manage events, objects emits signal which you connect to slots. Often you just have to connect them together with no extra code. If I want to implement a backbutton to work with a QWebview, I just have to connect the clicked signal from the button to the back slot from the web view (one liner). - Encourages separation of your GUI and logic (very easy to change your GUI without impeding the rest of your program) - Better layout (this is subjective but I was fighting all the time with Swing's and not Qt's) - Better organisation (subjective again but I find it much easier to find my way around Qt) That's all I can think of at the moment. Overall, I don't think Swing is terrible toolkit but Qt definitly feels a lot better to me. You can check this blog post to have an overview on how to use it in clojure: http://briancarper.net/2008/10/31/qt4-in-lisp/ --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
Thanks Rich! :-) > , 2009, at 11:25 AM, David Nolen wrote: > >> >> butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym, >> macroexpand, macroexpand-1, mapcat, nthrest >> >> >> -1 >> >> Because they are similar to other Lisps I assume. The same reason >> for println vs print-line. Changing these are a bad idea in IMHO. >> >> Breaking the meaning of rest with Common Lisp is a consideration to >> take seriously. However as long as the documentation clearly states >> (highlights in big bold colors ;) this difference (and the fact the >> operation is support by next) then I think this is a change people >> can live with. > > > Changing these names is not on the table. > > 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 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: Fully lazy sequences are coming - feedback wanted!
I agree with Walt, and there is no need to pressure the Prags, we are on it! :-) That said, it would be *very* helpful to me if we could get the lazyness thing settled this week... Stuart > Regarding Programming Clojure: > > I think that placing the burden of "book vs actual" incompatibility > upon Rich is misplaced. If anything, pressure from the Clojure > community should be placed on the Pragmatic Programmers to allow > Stuart to "do the right thing" regarding when the book is released, > viz., when Clojure has stabilized. > > Realize who is making the open contribution and who is profiting from > that contribution and keep the priorities straight. > > My 2 cents. > > Walt > > --~--~-~--~~~---~--~~ 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 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's version display
Got the idea.
Thanks Steve.
On Mon, Feb 16, 2009 at 5:58 PM, Stephen C. Gilardi wrote:
>
> On Feb 16, 2009, at 3:39 AM, Alin Popa wrote:
>
> Hi,
>>
>> There is a way to display the current clojure's version ?
>> Something like java -cp $CLOJURE_JAR:$CLOJURE_CONTRIB_JAR clojure.main -v
>>
>> Thanks.
>>
>> Alin
>>
>
> I think if a Clojure version identifier existed, that would be a good way
> to print it. I support an issue to request that when version info exists, it
> be made available through a "-v" or "--version" argument on clojure.main.
>
> Currently, there is no clean way to provide a Clojure version number. Some
> ways based on SVN revision have been proposed, but my impression is that
> there hasn't been consensus that it would be something that could be ensured
> to be correct automatically enough to be useful.
>
> Sometime there will be Clojure releases with version numbers. At that time,
> it seems most natural to me for version info to be available via a global
> variable like "*clojure-version*" whose value might be a small map like
> {:release true :major 1 :minor 0 :revision 0 :date "20090101T"} for
> release builds and {:release false :date 20090204T093247} for unofficial
> builds.
>
> No such mechanism is yet available.
>
> --Steve
>
>
--
Best Regards,
Alin
--~--~-~--~~~---~--~~
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
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: Anonymous recursive functions
There's a couple of Fibonacci's on the wiki that uses this approach: http://en.wikibooks.org/wiki/Clojure_Programming/Examples#Lazy_Fibonacci On Mon, Feb 16, 2009 at 6:50 PM, Konrad Hinsen wrote: > > I just discovered a nice feature that I don't remember having seen > discussed or documented before: there is a way to write recursive > functions without having them associated to any var/symbol in any > namespace. The optional name of a function can be used for a > recursive call. Example: > > ((fn fac [n] (if (zero? n) 1 (* n (fac (dec n) 5) > > I know this is not the best way to write a factorial (it is not tail- > recursive), the point is just to show an example of a recursive call. > > Konrad. > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: why fn key doesn't do what I want?
Thanks, 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 15, 12:18 pm, Rich Hickey wrote: > I'm pretty much finished with the fully-lazy implementation and am > happy so far with the results. I think this will be an important > addition to Clojure and am planning to add it. Thanks all for the feedback! It seems the Sequence/ISeq dichotomy was a sticking point for many. After some tweaking, I've been able to get rid of Sequence entirely, SVN 1284+ in lazy branch. This is source compatible with 1282 (first/ rest/next), except that sequence? no longer exists - go back to seq?. New docs here: http://clojure.org/lazy Let me know if that is simpler. 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2:22 pm, Mibu wrote: > rest is expected to be a sequence by Lispers, and next is expected to > be an item by Java-ers. I actually think next is pretty close to the next method on Java iterators. In java.util.Iterator, the next method evaluates the next item, increments state the iterator, then returns the evaluated item. In Clojure, the next function evaluates the next time, then returns a cons containing the evaluated item and the Clojure equivalent of an incremented iterator. It's essentially the functional equivalent of the Java method. Regarding Lispers, Clojure already differs from common Lisp in that nil != (). I think the proposed lazier changes make rest more consistant; instead of returning a collection or nil, it just returns a collection. Philosophically, I think this is closer to the idea of a cons cell than it was previously. Of course, this is all just my opinion :) - James --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
We are in production and we fully agree, this thing should be settled now. In fact if it's done within 10 days, that would fit our current plans. For reasons out of our control we have been postponing an update to prod., we still have a window to get this change out. It's feasible to do the code changes and run a test suite against the new runtime within two weeks, maybe less. Luc On Mon, 2009-02-16 at 13:22 -0500, Stuart Halloway wrote: > I agree with Walt, and there is no need to pressure the Prags, we are > on it! :-) > > That said, it would be *very* helpful to me if we could get the > lazyness thing settled this week... > > Stuart > > > Regarding Programming Clojure: > > > > I think that placing the burden of "book vs actual" incompatibility > > upon Rich is misplaced. If anything, pressure from the Clojure > > community should be placed on the Pragmatic Programmers to allow > > Stuart to "do the right thing" regarding when the book is released, > > viz., when Clojure has stabilized. > > > > Realize who is making the open contribution and who is profiting from > > that contribution and keep the priorities straight. > > > > My 2 cents. > > > > Walt > > > > > > > > --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
Thanks, -- Laurent 2009/2/16 Dan > > Hello, >> >> Do you know of a good pointer that goes beyond the "don't use it" >> argument, and really makes a thorough comparison of pros and cons of the 2 >> frameworks ? >> > > I'm not saying don't use Swing, I'm saying prefer Jambi. > > My memory of Swing is dated so I'd have trouble making a thorough > comparison but I can provide an outline. > > In favour of Swing: > > - No extra dependencies > - No license restriction (Qt 4.4 requires you to buy a commercial license > if you don't want to opensource your app, won't be true anymore with Qt 4.5) > - De facto standard > - Instantly cross-platform (Jambi requires you to package a different jar > for each platform) > > In favour of Qt: > > - Great GUI builder (optional of course but you should give it a try, it's > powerful and doesn't get in your way) > - Cross-language (you can easily use the same GUI in C++, Python, Java, > Ruby, Perl, and a few others with minimal porting efforts > - Signals and slots, great way to manage events, objects emits signal which > you connect to slots. Often you just have to connect them together with no > extra code. If I want to implement a backbutton to work with a QWebview, I > just have to connect the clicked signal from the button to the back slot > from the web view (one liner). > - Encourages separation of your GUI and logic (very easy to change your GUI > without impeding the rest of your program) > - Better layout (this is subjective but I was fighting all the time with > Swing's and not Qt's) > - Better organisation (subjective again but I find it much easier to find > my way around Qt) > > That's all I can think of at the moment. Overall, I don't think Swing is > terrible toolkit but Qt definitly feels a lot better to me. > > You can check this blog post to have an overview on how to use it in > clojure: > > http://briancarper.net/2008/10/31/qt4-in-lisp/ > > > > > --~--~-~--~~~---~--~~ 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 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: A Clojure documentation browser
> I think a problem with the current layout is that once you jump to one > of the library sections you have to manually scroll back up to the > index. There are a few different ways this could be solved. > > a) You could just add a "top" link to each library section banner. > > b) Only show the currently selected library, and hide the rest. > > c) Same as above, but also change the library navigation to a tree > view. > > -> clojure.contrib.duck-streams > -) *default-encoding* > -) file > -) pwd I usually just hit "home", but I'm a keyboard kind of guy, and I realize that not everyone is. > I did a quick implementation of B, and I think it makes the page feel > less cluttered (but I still feel it could be better). However, I did > add jQuery as a dependency. I'm not sure how 'light' you were trying > to keep this, but jQuery could simplify your JS. Here is a diff: I don't have a problem with jQuery per se, but I was really going for something that would all live in one file, so that you can browse it when disconnected, so that it's easy to copy around without having to grab extra files, etc. etc. You'll notice there are no graphics, for the same reason. Although I've considered using SVG to get around that. > Do with my idea as you wish. I just wanted to to throw it out there. Appreciate the feedback. My current plan is to leave it as is. Not because I don't think your ideas have merit, but because this thing started out as something I was poking around with for half an hour...and then I spent a week working on it. So I'm sort of at the point where the quality ascended to the point where it met the decreasing trajectory of my interest. :) > I also think the code would be cleaner with the JS and CSS in their > own files, but I admit having everything in-lined makes it easy to > call. I would generally prefer things that way as well, but again I really wanted to have the file be self-contained. > Oh, almost forgot--if you do happen to try out my patch you will > notice all the links from 'miglayout.internal' on will not behave > correctly. If you look at the DOM with Firebug you'll notice that the > 'miglayout' DIV is not being closed and is capturing the others. I > didn't have a chance to track down the problem, but you might want to > take a look. Hmm. OK - that I'll have to check out. I have noticed that the docstring elision gets a little confused when there are quotes or backslashes in the docs. I haven't yet figured out if that's an issue with my code or prxml. This could be related. Thanks for the feedback! --~--~-~--~~~---~--~~ 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 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: compiling a GUI app and also: interference of Java's built-in architechture
I would have to strongly disagree that QT is a good idea for clojure development. I have posted about this several times before but I find that QT isn't ready for heavy java dev just yet, at least on the mac. 1. QT jambi will not run on the mac unless you are using java 1.5. This is because QT is using the carbon API below to implement its interfaces and the mac version of java 1.6 doesn't support the carbon API, it is 64 bit which means you are going 100% cocoa. So no java 1.6 for you. 2. QT's event handing is very sensitive to threading issues. This boils down to when you are developing from the repl you will most likely get hangs. You have to use odd options on the java invocation or your process will hang permanently. 3. Forget about openGL with QT, at least on the mac. Running any JOGL (or lwjgl) code starts an initialization system that fires up some swing threads. If you are running from the repl, you can bet this will hang your machine due to #2 above. I am not certain what other situations will hang but I assure you it is irrecoverable when it does. I believe you can create very good looking applications with swing, builder or otherwise as many people have done so (not that it is easy). I do believe a builder is a giant step forward but only if you have a design team that you would like to separate from your coding team. If it is just you, then a builder really doesn't add that much. Both systems allow separation between view and model or any event system you would like. So that is a non-issue. The points I have stated above very much are issues you will have to take care of. One thing I think would be useful for clojure would be clojure.contrib.swing that has functions that create various callback listeners just from a function (wrap the proxy generation) and such, as well as various macros I have written for dealing with GridBagLayout etc. If you decide to go this way you should let me know as I would like to show some of them to you and perhaps we could start the process of formalizing them into clojure.contrib. Chris On Feb 16, 12:36 pm, Laurent PETIT wrote: > Thanks, > > -- > Laurent > > 2009/2/16 Dan > > > > > Hello, > > >> Do you know of a good pointer that goes beyond the "don't use it" > >> argument, and really makes a thorough comparison of pros and cons of the 2 > >> frameworks ? > > > I'm not saying don't use Swing, I'm saying prefer Jambi. > > > My memory of Swing is dated so I'd have trouble making a thorough > > comparison but I can provide an outline. > > > In favour of Swing: > > > - No extra dependencies > > - No license restriction (Qt 4.4 requires you to buy a commercial license > > if you don't want to opensource your app, won't be true anymore with Qt 4.5) > > - De facto standard > > - Instantly cross-platform (Jambi requires you to package a different jar > > for each platform) > > > In favour of Qt: > > > - Great GUI builder (optional of course but you should give it a try, it's > > powerful and doesn't get in your way) > > - Cross-language (you can easily use the same GUI in C++, Python, Java, > > Ruby, Perl, and a few others with minimal porting efforts > > - Signals and slots, great way to manage events, objects emits signal which > > you connect to slots. Often you just have to connect them together with no > > extra code. If I want to implement a backbutton to work with a QWebview, I > > just have to connect the clicked signal from the button to the back slot > > from the web view (one liner). > > - Encourages separation of your GUI and logic (very easy to change your GUI > > without impeding the rest of your program) > > - Better layout (this is subjective but I was fighting all the time with > > Swing's and not Qt's) > > - Better organisation (subjective again but I find it much easier to find > > my way around Qt) > > > That's all I can think of at the moment. Overall, I don't think Swing is > > terrible toolkit but Qt definitly feels a lot better to me. > > > You can check this blog post to have an overview on how to use it in > > clojure: > > >http://briancarper.net/2008/10/31/qt4-in-lisp/ --~--~-~--~~~---~--~~ 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 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: New lazy branch of clojure-contrib
It would be nice if patches were accompanied by failing (and after patching, fixed) tests so that we can get a higher level of formalism and confidence out of both clojure and clojure.contrib. These tests would also be good lessons for newer people about some of the gotchas with lazy eval. Chris On Feb 16, 10:23 am, Stuart Sierra wrote: > I created a lazy branch of clojure-contrib to track patches to contrib > that are needed in the lazy branch of Clojure. > > For clojure-contrib hackers: > svn checkouthttps://clojure-contrib.googlecode.com/svn/branches/lazy > clojure-contrib-lazy --username your.google.account > > For everyone else: > svn checkouthttp://clojure-contrib.googlecode.com/svn/trunk/clojure- > contrib-lazy > > -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
terminology question re: binding
David Sletten sent me this erratum: << At the beginning of section 2.4 we have "The symbol user/foo refers to a var which is bound to the value 10." Under the next subsection "Bindings" we have "Vars are bound to names, but there are other kinds of bindings as well." The Common Lisp standard defines a binding as "an association between a name and that which the name denotes". This is the second sense used in the book. The first sense of a "binding" between a var and its value is inconsistent. >> Should I be using two different terms, or is the notion of binding overloaded? Stuart --~--~-~--~~~---~--~~ 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 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: New lazy branch of clojure-contrib
Isn't that second url just the normal one for contrib trunk? On Mon, Feb 16, 2009 at 12:23 PM, Stuart Sierra wrote: > > I created a lazy branch of clojure-contrib to track patches to contrib > that are needed in the lazy branch of Clojure. > > For clojure-contrib hackers: > svn checkout https://clojure-contrib.googlecode.com/svn/branches/lazy > clojure-contrib-lazy --username your.google.account > > For everyone else: > svn checkout http://clojure-contrib.googlecode.com/svn/trunk/ clojure- > contrib-lazy > > -Stuart Sierra > > > --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2009, at 2:23 PM, Rich Hickey wrote: New docs here: http://clojure.org/lazy In the html doc: rest... "returns a possibly empty seq, never nil" then later "never returns nil - currently not enforced on 3rd party seqs" In "(doc rest)" "may return nil" What's the cleaned up version of all that? Is it worth guaranteeing that rest never returns nil or should "never returns nil" be removed from the html docs? --Steve smime.p7s Description: S/MIME cryptographic signature
Re: New lazy branch of clojure-contrib
On Feb 16, 2009, at 3:52 PM, Jeffrey Straszheim wrote: Isn't that second url just the normal one for contrib trunk? Yes, you should replace "trunk" with "branches/lazy" there as well. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: New lazy branch of clojure-contrib
On Feb 16, 3:52 pm, Jeffrey Straszheim wrote: > Isn't that second url just the normal one for contrib trunk? Oops, sorry. svn checkout http://clojure-contrib.googlecode.com/svn/branches/lazy/ clojure- contrib-lazy --~--~-~--~~~---~--~~ 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 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: error-kit + test-is
On Feb 16, 12:13 pm, David Nolen wrote: > test-is + error-kit is a great combo. Let me know if I can answer any questions about test-is, but you seem to have it well in hand. :) -Stuart Sierra --~--~-~--~~~---~--~~ 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 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: New lazy branch of clojure-contrib
Good. I was worried I'd be forced over to the Lazy branch before I was ready. :) On Mon, Feb 16, 2009 at 4:05 PM, Stephen C. Gilardi wrote: > > On Feb 16, 2009, at 3:52 PM, Jeffrey Straszheim wrote: > > Isn't that second url just the normal one for contrib trunk? >> > > Yes, you should replace "trunk" with "branches/lazy" there as well. > > --Steve > > --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2009, at 3:56 PM, Stephen C. Gilardi wrote: > > On Feb 16, 2009, at 2:23 PM, Rich Hickey wrote: > >> New docs here: >> >> http://clojure.org/lazy > > > In the html doc: > > rest... "returns a possibly empty seq, never nil" > > then later > > "never returns nil > - currently not enforced on 3rd party seqs" > > In "(doc rest)" > > "may return nil" > > What's the cleaned up version of all that? Is it worth guaranteeing > that rest never returns nil or should "never returns nil" be removed > from the html docs? > I've fixed the doc string. I'm not going to add code for 3rd party seqs, enforcing this contract is up to them. If they derive from ASeq and define next, ASeq will do the right thing for them. 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 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: terminology question re: binding
On Mon, Feb 16, 2009 at 3:34 PM, Stuart Halloway wrote: > > David Sletten sent me this erratum: > > << > At the beginning of section 2.4 we have "The symbol user/foo refers to > a var which is bound to the value 10." Under the next subsection > "Bindings" we have "Vars are bound to names, but there are other kinds > of bindings as well." The Common Lisp standard defines a binding as > "an association between a name and that which the name denotes". This > is the second sense used in the book. The first sense of a "binding" > between a var and its value is inconsistent. > >> > > Should I be using two different terms, or is the notion of binding > overloaded? Clojure does have another term already for that first meaning: (def x 5) ==> #'user/x (.hasRoot #'x) ==> true (.getRoot #'x) ==> 5 I don't know if it's more correct, but it might be less confusing to say "The symbol user/foo is bound to a var which has a root value of 10". --Chouser --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
How about e-rest, for the empty set returning version? Perry Trolard wrote: If it's the case that rest will almost exclusively appear in the context of constructing lazy-seqs (lazy-seq (cons [something] (rest [something])) & next will appear all over, it makes sense to me to sacrifice brevity in the case of rest, & give next the right name: "rest" --~--~-~--~~~---~--~~ 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 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: terminology question re: binding
On Mon, Feb 16, 2009 at 5:29 PM, Chouser wrote: > > I don't know if it's more correct, but it might be less confusing to > say "The symbol user/foo is bound to a var which has a root value of > 10". Eh, well, I'm not sure about that first part. I don't know if the symbol is bound to the var or not. But the var does has a root value of 10. :-) --Chouser --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
Browsing the source code for LazySeq, I noticed that isEmpty is
implemented as follows:
public boolean isEmpty() {
return count() == 0;
}
Since count realizes the whole list, this seems like a bad way to test
for empty on a lazy sequence.
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
state monad transformer
Konrad, Here's a shot at implementing a monad transformer for the state monad. Any chance of getting it added to clojure.contrib.monads? (defn state-t [m] (monad [m-result (with-monad m (fn [v] (fn [s] (m-result (list v s) m-bind (with-monad m (fn [stm f] (fn [s] (m-bind (stm s) (fn [[v ss]] ((f v) ss)) m-zero (with-monad m (when (not= ::undefined m-zero) (fn [s] m-zero))) m-plus (with-monad m (when (not= ::undefined m-zero) (fn [& stms] (fn [s] (apply m-plus (map #(% s) stms)) ])) I've also about finished with the first draft of a monad tutorial for Clojure based on clojure.contrib.monads. Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Fully lazy sequences are coming - feedback wanted!
On Feb 16, 2009, at 5:35 PM, Mark Engelberg wrote:
>
> Browsing the source code for LazySeq, I noticed that isEmpty is
> implemented as follows:
>public boolean isEmpty() {
>return count() == 0;
>}
>
> Since count realizes the whole list, this seems like a bad way to test
> for empty on a lazy sequence.
>
>
Fixed in (lazy) 1286 - thanks for the report.
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
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
-~--~~~~--~~--~--~---
Clojure on CLR/DLR
[I thought I'd slip this in while Rich has everyone distracted lazy sequences.] What do you do when you love Lisp, are intrigued by Clojure, but have absolutely no projects at hand to test it out? Oh, and you have an interest in how dynamic languages are being implemented in modern virtual machine environments. You might implement Clojure on the CLR, I guess. So I did. At least, I have started. The project has reached the point where I need input from the community and especially Rich. Rich asked that I go public. So I will. (Though most certainly I would prefer to wait until the code is ... better.) The code will go up on clojure-contrib ASAP. I need input from the clojure-contrib project members on how they operate, where they want to put it, etc. This is definitely alpha-level, developer-only. Hard hats, goggles, and heavy gloves recommended. Goals: (a) Implement a feature-complete Clojure on top of CLR and the DLR (Dynamic Language Runtime). (b) Stay as close as possible to the JVM implementation so that the versions can stay in synch. That includes: (c) To the extent possible, use exactly the same boostrap *.clj files to define the environment. (d) Try to use some of the more advanced features of the DLR, where it makes sense to do so. (e) Spawn a cottage industry of people making Visual Studio extensions for Clojures. :) (e) Have fun. Status: Let's call it alpha. Not for the casual user, but developers might want to take a look. Stop here unless you really want status details. The basic runtime data structures--the persistent collections, namespaces/symbols/keywords, vars, refs, atoms, agents, etc.--are 95% complete. The remaining pieces are trivial. The LispReader is feature-complete except for #=. Call this 96% complete. There are currently 500+ unit tests on the basic data structures and the reader. Call this 34% complete. There are no unit tests on compiler. That would be 0%. This is not an interpreter. A compiler translates Clojure forms into DLR expression trees. DLR does its magic, i.e. compiles to MSIL, and computation happens. At the moment, there is not a single call to Reflection.Emit in the compiler code. (Though that will have to change soon.) It handles all special forms, can load most of core.clj, deals with macros, inlines, tags, CLR-interop, There is a basic REPL. core.clj loads with minor edits (java.util.Collection => System.Collections.ICollection, for example). Of roughly 425 def forms in core.clj, only 43 are commented out. 19 of those are for specialized array access, 6 for regular expressions -- nothing significant in terms of work. Of the 360 defs that load, most have been tested at a rudimentary level. However, the roughly 20 defs related to libs/loading/compiling definitely do not work. Call this 85% complete. core-print.clj also loads and seems to work. ants.clj runs. (The sim code is unchanged. The GUI was rewritten to Windows Forms.) 100%. The code is consistent with revision 1279 of the JVM code (Feb 13). It is running on release 10606 of the DLR (Feb 11). It is slow. Roughly 4X slower than Clojure/JVM on one or two very easy tests. (No need to comment on microbenchmarks.) This will be the focus of the next round of work. What's not there: Libs and loading -- lots of design problems because of the differences between JVM and CLR relating to classpaths, assemblies, etc. (Basic file loads can be done.) AOT/Compilation/gen-class Proxies Bootstrap *.clj files other than core.clj and core-print.clj -- Just haven't had time yet. Speed. So there you have it. I'll post again when the code becomes available on clojure-contrib. -- David Miller --~--~-~--~~~---~--~~ 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 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: Newbie: Separating and grouping the elements in a bunch of vectors
And to get the enclosing vector: (reduce conj [] (apply map vector [[:a :b] [1 2] ['a 'b]])) 2009/2/16 David Nolen > > I'm sure it can be done, but it's not clear to me if you have a vector of >> vectors >> how Stuart's solution would work: >> >> 1:15 user=> (map vector vecs) > > ([[:a0 :a1 :a2]] [[:b0 :b1 :b2]]) > > > (apply (partial map vector) [[1 2 3] ['a 'b 'c] ["cat" "dog" "bird"]]) > > works on a vector of vectors. The OP wanted a vector of vectors as a result > where the subvector length is the same as the number of vectors originally > passed 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 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 on CLR/DLR
Awesome! On Mon, Feb 16, 2009 at 5:43 PM, dmiller wrote: > > [I thought I'd slip this in while Rich has everyone distracted lazy > sequences.] > > > What do you do when you love Lisp, are intrigued by Clojure, but have > absolutely no projects at hand to test it out? Oh, and you have an > interest in how dynamic languages are being implemented in modern > virtual machine environments. > > You might implement Clojure on the CLR, I guess. So I did. At least, > I have started. > > The project has reached the point where I need input from the > community and especially Rich. Rich asked that I go public. So I > will. (Though most certainly I would prefer to wait until the code > is ... better.) > > The code will go up on clojure-contrib ASAP. I need input from the > clojure-contrib project members on how they operate, where they want > to put it, etc. > > This is definitely alpha-level, developer-only. Hard hats, goggles, > and heavy gloves recommended. > > > Goals: > > (a) Implement a feature-complete Clojure on top of CLR and the DLR > (Dynamic Language Runtime). > (b) Stay as close as possible to the JVM implementation so that the > versions can stay in synch. That includes: > (c) To the extent possible, use exactly the same boostrap *.clj files > to define the environment. > (d) Try to use some of the more advanced features of the DLR, where it > makes sense to do so. > (e) Spawn a cottage industry of people making Visual Studio extensions > for Clojures. :) > (e) Have fun. > > > Status: > > Let's call it alpha. Not for the casual user, but developers might > want to take a look. > > Stop here unless you really want status details. > > > The basic runtime data structures--the persistent collections, > namespaces/symbols/keywords, vars, refs, atoms, agents, etc.--are 95% > complete. The remaining pieces are trivial. > > The LispReader is feature-complete except for #=. Call this 96% > complete. > > There are currently 500+ unit tests on the basic data structures and > the reader. Call this 34% complete. > There are no unit tests on compiler. That would be 0%. > > This is not an interpreter. A compiler translates Clojure forms into > DLR expression trees. DLR does its magic, i.e. compiles to MSIL, and > computation happens. At the moment, there is not a single call to > Reflection.Emit in the compiler code. (Though that will have to > change soon.) It handles all special forms, can load most of > core.clj, deals with macros, inlines, tags, CLR-interop, > > There is a basic REPL. > > core.clj loads with minor edits (java.util.Collection => > System.Collections.ICollection, for example). Of roughly 425 def > forms in core.clj, only 43 are commented out. 19 of those are for > specialized array access, 6 for regular expressions -- nothing > significant in terms of work. Of the 360 defs that load, most have > been tested at a rudimentary level. However, the roughly 20 defs > related to libs/loading/compiling definitely do not work. Call this > 85% complete. > > core-print.clj also loads and seems to work. ants.clj runs. (The sim > code is unchanged. The GUI was rewritten to Windows Forms.) 100%. > > The code is consistent with revision 1279 of the JVM code (Feb 13). > It is running on release 10606 of the DLR (Feb 11). > > It is slow. Roughly 4X slower than Clojure/JVM on one or two very > easy tests. (No need to comment on microbenchmarks.) This will be the > focus of the next round of work. > > > What's not there: > > Libs and loading -- lots of design problems because of the differences > between JVM and CLR relating to classpaths, assemblies, etc. (Basic > file loads can be done.) > > AOT/Compilation/gen-class > > Proxies > > Bootstrap *.clj files other than core.clj and core-print.clj -- Just > haven't had time yet. > > Speed. > > > So there you have it. I'll post again when the code becomes available > on clojure-contrib. > > -- David Miller > > > > > > --~--~-~--~~~---~--~~ 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 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: terminology question re: binding
On Feb 16, 3:34 pm, Stuart Halloway wrote: > Should I be using two different terms, or is the notion of binding > overloaded? I think it's overloaded. In Common Lisp, symbols are bound to values. Clojure's Vars are closer to CL symbols than Clojure symbols are to CL symbols. (!) It's funky because CL docs talk of "binding" symbols to values. I like to think of both CL symbols and Clojure Vars as "storage locations." As I understand it, every Var has a name, which is a symbol, but the name is an inherent property of the Var and cannot be changed. You can "bind" a Var to different values with def, binding, var-set, set!, and alter-var-root. But you never "bind" a Var to a different name. Within a namespace, a Var may be "mapped" to a name (a symbol). There is ns-unmap to remove a mapping, but no corresponding function to add a mapping. All you have is "refer". I await corrections. :) -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Embed A Struct Within A Struct
Hi all,
Is it possible to have a structure nested within a structure in
Clojure? Consider the following code:
(defstruct rect :height :width)
(defstruct color-rect :color (struct rect))
(defn
#^{:doc "Echoes the details of the rect passed to it"}
echo-rect
[r]
(println (:color r))
(println (:height r))
(println (:width r)))
(def first-rect (struct rect 1 2))
;(def c-rect1 (struct color-rect 249 first-rect)) ;form 1
;output "249 nil nil"
(def c-rect1 (struct color-rect 249 1 2)) ;form 2
;output "Too many arguments to struct constructor
(echo-rect c-rect1)
Of course this is a contrived example but there are cases where I want
to break a large data structure into smaller substructures to make
code easier to maintain. As the comments indicate if I do form 1 I get
"249 nil nil" but if I do form 2 I get "Too many arguments to struct
constructor".
If I'm approaching this issue in the wrong way, please tell me what I
should be doing. I did search this group but I failed to turn up
anything that seemed helpful.
--
Onorio Catenacci
--~--~-~--~~~---~--~~
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
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 on CLR/DLR
On Mon, Feb 16, 2009 at 5:43 PM, dmiller wrote: > > The code will go up on clojure-contrib ASAP. I need input from the > clojure-contrib project members on how they operate, where they want > to put it, etc. I don't know if you've looked at ClojureScript at all, but it's a similar if noticeably less ambitious project to compile Clojure code to JavaScript. It's in clojure-contrib already, but in trunk/clojurescript instead of trunk/src. My reasons for this were (1) I wasn't quite sure how to lay out the directory structure and didn't want to mess up anyone else, and (2) it doesn't work with Clojure trunk but instead requires a patch and rebuild of Clojure itself. This patch is stored right there in contrib as well. I think I've worked out (1) well enough, but (2) is still a factor. As it is, I never get complaints from people trying to use it with an unpatched Clojure and getting errors. Then again that may have more to do with the inscrutability and lack of docs. :-) Once Rich has applied the patch and ClojureScript can work with a regular build of Clojure (or at least as well there as anywhere), I plan to move the files into trunk/src/clojure/contrib/clojurescript I don't know if that same idea would be appropriate for your project, but it does make the code accessible without people using it accidentally. > The basic runtime data structures--the persistent collections, > namespaces/symbols/keywords, vars, refs, atoms, agents, etc.--are 95% > complete. The remaining pieces are trivial. Fantastic! For ClojureScript, at least, that has been the bulk of the work. > core.clj loads with minor edits (java.util.Collection => > System.Collections.ICollection, for example). Of roughly 425 def > forms in core.clj, only 43 are commented out. 19 of those are for > specialized array access, 6 for regular expressions -- nothing > significant in terms of work. This is the majority of what the ClojureScript patch changes -- moving explicit uses of non-Clojure Java class names out of .clj files and into clojure.lang.RT (or other appropriate Clojure classes) so that the .clj can be loaded as-is. RT and Numbers have to be ported by hand anyway, so it's not significantly worse on that end. I'd be very interested to compare notes and see if our needs have a common solution. > So there you have it. I'll post again when the code becomes available > on clojure-contrib. Sounds great! But there's one very important question you didn't address. What are you going to call it? :-) Seriously, though, since it seems likely that a majority of code written to run on your port will not work on Clojure/JVM, because of the runtime libs available (please correct me if I'm wrong), it's important for a body of code to be able to clearly declare where it's supposed to work. A name that is used consistently can help, I would think. --Chouser --~--~-~--~~~---~--~~ 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 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: Fully lazy sequences are coming - feedback wanted!
I definitely support your second option; first / rest / next. In my mind, rest means "collection of remaining items" and should return a collection, and next will also do exactly what I would expect it to do. Clojure is sufficiently different from Common Lisp already that breaking the compatibilty of rest is a non-issue for me. As others have mentioned, a big part of the appeal of Clojure is being involved in the early stages of a language that has a real opportunity to grow "cleanly", with developer input and without the inertia of layers of past compromises. I really like Clojure so far, and thank Rich and the other main contributors for their work. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Is this a bug ?!?
Ok, perhaps I'm just dumb, but I have the problem with the following
code:
(import '(java.util ArrayList Collections))
(defn shuffle-java
"Shuffles coll using a Java ArrayList."
[coll]
(let [l (ArrayList. coll)]
(Collections/shuffle l)
(seq l)))
(defn- nodes-num [x-dim y-dim] (* x-dim y-dim))
(defn- states-num [x-dim y-dim] (* 4 x-dim y-dim))
(defn- particles-num [density nodes-num]
"Given a particle density between 0 and 1 and the number of nodes,
the funct. returns the rounded number of particles"
(int (* 4 density nodes-num)))
(defn- get-init-states [states-num particles-num]
"Returns the a shuffled sequence of states."
(doall (shuffle-java (concat (take particles-num (repeat 1))
(take (- states-num particles-num) (repeat
0))
(defn initialize-domain [x-dim y-dim density]
(let [nodes (nodes-num x-dim y-dim) states (states-num x-dim y-dim)
particles (particles-num density nodes)
seq-of-states (get-init-states states particles)]
(into {} (for [i (range x-dim) j (range y-dim)] {[i j] (vec (take
4 seq-of-states))}
(initialize-domain 4 4 0.3)
When you look at resulting hash, which you get by calling
"(initialize-domain 4 4 0.3)",
you see that the 4-component value vector of every key is "not so"
random. In fact it is the same vector every time.
But when I modify the "initialize-domain" function by deleting the
"seq-of-states" binding, and making a direct call to
the "get-init-states" function, the result is correct, i.e. for every
key in the resulting hash, the associated vector is random.
The "initialize-domain" function which yields the correct result is
this:
(defn initialize-domain [x-dim y-dim density]
(let [nodes (nodes-num x-dim y-dim) states (states-num x-dim y-dim)
particles (particles-num density nodes)]
(into {} (for [i (range x-dim) j (range y-dim)] {[i j] (vec (take
4 (get-init-states states particles)))}
I'm puzzled, please help.
Thank you, Oliver.
--~--~-~--~~~---~--~~
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
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 on CLR/DLR
On Feb 16, 5:33 pm, Chouser wrote: > On Mon, Feb 16, 2009 at 5:43 PM, dmiller wrote: > > I don't know if you've looked at ClojureScript at all, but it's a > similar if noticeably less ambitious project to compile Clojure code to > JavaScript. It's in clojure-contrib already, but in > trunk/clojurescript instead of trunk/src. My reasons for this were > (1) I wasn't quite sure how to lay out the directory structure and > didn't want to mess up anyone else, and (2) it doesn't work with > Clojure trunk but instead requires a patch and rebuild of Clojure > itself. This patch is stored right there in contrib as well. > I have looked briefly at ClojureScript. Placement: I'm guessing a parallel off-trunk placement. This code is completely independent of Clojure/JVM, except for the bootstrap *.clj files. I have those included in the project, so I'm not broken by Clojure/JVM changes. Also, this code is not set up for casual play. You need to be in Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm thinking it should not be in trunk/src by the criteria you cite. > This is the majority of what the ClojureScript patch changes -- moving > explicit uses of non-Clojure Java class names out of .clj files and > into clojure.lang.RT (or other appropriate Clojure classes) so that > the .clj can be loaded as-is. RT and Numbers have to be ported by > hand anyway, so it's not significantly worse on that end. > > I'd be very interested to compare notes and see if our needs have a > common solution. > I need to make the same kinds of changes to the *.clj files. This has not been automated yet, so being in synch is a matter of hand- editing. We most definitely need to compare notes. > Sounds great! But there's one very important question you didn't > address. What are you going to call it? :-) > > Seriously, though, since it seems likely that a majority of code > written to run on your port will not work on Clojure/JVM, because of > the runtime libs available (please correct me if I'm wrong), it's > important for a body of code to be able to clearly declare where it's > supposed to work. A name that is used consistently can help, I would > think. > This is 100% C#/.NET. I'm up for suggestions on the name. The obvious ones: - Clojure.net - ClojureCLR - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron trademarked.) - CLjR (too cute) Perhaps Rich will have a preference. He'll have to live with it longer than anyone and has branding/confusion issues to keep in mind. -- David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Embed A Struct Within A Struct
You can nest structs in structs like this:
(defstruct rect :height :width)
(defstruct colored-rect :color :shape)
(def subject (struct colored-rect :red (struct rect 50 30)))
(println subject) ; prints {:color :red, :shape {:height 50, :width
30}}
The defstruct macro takes a var and a bunch of keys for the struct.
Trying to do:
(defstruct color-rect :color (struct rect))
means you're trying to pass in a rectangle struct itself as a key.
On Feb 16, 4:25 pm, Onorio Catenacci wrote:
> Hi all,
>
> Is it possible to have a structure nested within a structure in
> Clojure? Consider the following code:
>
> (defstruct rect :height :width)
> (defstruct color-rect :color (struct rect))
>
> (defn
> #^{:doc "Echoes the details of the rect passed to it"}
> echo-rect
> [r]
> (println (:color r))
> (println (:height r))
> (println (:width r)))
>
> (def first-rect (struct rect 1 2))
> ;(def c-rect1 (struct color-rect 249 first-rect)) ;form 1
> ;output "249 nil nil"
> (def c-rect1 (struct color-rect 249 1 2)) ;form 2
> ;output "Too many arguments to struct constructor
>
> (echo-rect c-rect1)
>
> Of course this is a contrived example but there are cases where I want
> to break a large data structure into smaller substructures to make
> code easier to maintain. As the comments indicate if I do form 1 I get
> "249 nil nil" but if I do form 2 I get "Too many arguments to struct
> constructor".
>
> If I'm approaching this issue in the wrong way, please tell me what I
> should be doing. I did search this group but I failed to turn up
> anything that seemed helpful.
>
> --
> Onorio Catenacci
--~--~-~--~~~---~--~~
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
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: Newbie: Separating and grouping the elements in a bunch of vectors
Thanks a lot, everyone. Isn't (reduce conj [] (apply map vector [[:a :b] [1 2] ['a 'b]])) equivalent to (into [] (apply map vector [[:a :b] [1 2] ['a 'b]])) though? On Feb 16, 3:55 pm, Laurent PETIT wrote: > And to get the enclosing vector: > > (reduce conj [] (apply map vector [[:a :b] [1 2] ['a 'b]])) > > 2009/2/16 David Nolen > > > > > I'm sure it can be done, but it's not clear to me if you have a vector of > >> vectors > >> how Stuart's solution would work: > > >> 1:15 user=> (map vector vecs) > > > ([[:a0 :a1 :a2]] [[:b0 :b1 :b2]]) > > > (apply (partial map vector) [[1 2 3] ['a 'b 'c] ["cat" "dog" "bird"]]) > > > works on a vector of vectors. The OP wanted a vector of vectors as a result > > where the subvector length is the same as the number of vectors originally > > passed 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 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 on CLR/DLR
On Feb 16, 2009, at 7:17 PM, dmiller wrote: > > > > On Feb 16, 5:33 pm, Chouser wrote: >> On Mon, Feb 16, 2009 at 5:43 PM, dmiller >> wrote: >> > >> I don't know if you've looked at ClojureScript at all, but it's a >> similar if noticeably less ambitious project to compile Clojure >> code to >> JavaScript. It's in clojure-contrib already, but in >> trunk/clojurescript instead of trunk/src. My reasons for this were >> (1) I wasn't quite sure how to lay out the directory structure and >> didn't want to mess up anyone else, and (2) it doesn't work with >> Clojure trunk but instead requires a patch and rebuild of Clojure >> itself. This patch is stored right there in contrib as well. >> > > I have looked briefly at ClojureScript. > > Placement: I'm guessing a parallel off-trunk placement. This code is > completely independent of Clojure/JVM, except for the bootstrap *.clj > files. I have those included in the project, so I'm not broken by > Clojure/JVM changes. > > Also, this code is not set up for casual play. You need to be in > Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm > thinking it should not be in trunk/src by the criteria you cite. > > >> This is the majority of what the ClojureScript patch changes -- >> moving >> explicit uses of non-Clojure Java class names out of .clj files and >> into clojure.lang.RT (or other appropriate Clojure classes) so that >> the .clj can be loaded as-is. RT and Numbers have to be ported by >> hand anyway, so it's not significantly worse on that end. >> >> I'd be very interested to compare notes and see if our needs have a >> common solution. >> > > I need to make the same kinds of changes to the *.clj files. This has > not been automated yet, so being in synch is a matter of hand- > editing. > > We most definitely need to compare notes. > > >> Sounds great! But there's one very important question you didn't >> address. What are you going to call it? :-) >> >> Seriously, though, since it seems likely that a majority of code >> written to run on your port will not work on Clojure/JVM, because of >> the runtime libs available (please correct me if I'm wrong), it's >> important for a body of code to be able to clearly declare where it's >> supposed to work. A name that is used consistently can help, I would >> think. >> > > This is 100% C#/.NET. > > I'm up for suggestions on the name. The obvious ones: > > - Clojure.net > - ClojureCLR > - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron > trademarked.) > - CLjR (too cute) > > Perhaps Rich will have a preference. He'll have to live with it > longer than anyone and has branding/confusion issues to keep in mind. > I prefer ClojureCLR. 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 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 -~--~~~~--~~--~--~---
Is syntax quote "reader" only?
I'm a bit mystified how syntax quote does what it does. I don't see how syntax quote can quote the whole while unquoting parts without some evaluation-time intervention. If I had to implement it myself, I'd just punt the problem to evaluation-time by introducing a special form 'unquote', e.g.: `(a b ~(c d)) (quote ((unquote a) 3 (unquote (c d))) But this isn't what Clojure does, so I'm wondering, how does syntax quote do its business while remaining strictly a reader-time only mechanism? --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
How do I do this in clojure?
I'm trying to port some Python code to Clojure. I'm new to functional programming and I hit a function that is causing my brain to melt. The python function looks something like this: def build_table(): num_cols = 3 selected_row = 0 selected_col = 0 strings = ["cat", "dog", "", "rabbit", "frog", "elephant", "gorilla"] row, col = 0, 0 table_contents = "\n\n" for string in strings: if string == "": continue if col >= num_cols: row += 1 col = 0 table_contents += "\n" def new_cell(): bg_color = "cfcfdf" if(col == selected_col and row == selected_row): bg_color = "d0e0ff" return "" + \ "" + string[0] + \ "" + string[1:] + "\n" table_contents += new_cell() col += 1 table_contents += "\n" return table_contents If someone could please demonstrate how to do this in Clojure, I think it would greatly help my understanding of the language and functional programming in general. --~--~-~--~~~---~--~~ 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 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: How do I do this in clojure?
Suggestion: Provide a statement of purpose as to what this function is supposed to do. What are its inputs and what is its output? Can you break it down into smaller functions? Right now you have a complicated function that takes no inputs and always produces the same string. It seems somewhat nonsensical. Surely you want this function to take some inputs, and produce different strings depending on the input. Check out htdp.org as a resource for learning more about functional programming and good program design principles. --~--~-~--~~~---~--~~ 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 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: How do I do this in clojure?
On Feb 17, 1:18 pm, Jesse Aldridge wrote: > I'm trying to port some Python code to Clojure. I'm new to functional > programming and I hit a function that is causing my brain to melt. > The python function looks something like this: > [..] > > If someone could please demonstrate how to do this in Clojure, I think > it would greatly help my understanding of the language and functional > programming in general. You'll probably get a decent answer from someone, but if not, try rephrasing your question: "How do I do this in Clojure? [Insert concise, precise English description here]" Reason being: your code has too much low-level detail in it for me to parse effectively. Others may be more willing to slog away at it and work out what specifically is causing you trouble. Cheers, Gavin --~--~-~--~~~---~--~~ 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 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: How do I do this in clojure?
Minus the bad html, you'll want something like this: (defn make-table "Make an html table n rows wide from collection col." [col n] (let [make-row (fn [row] (let [cont (map #(str "" % "") row)] (apply str "" (conj (vec cont) "" cont (map make-row (partition n col))] (apply str "" (conj (vec cont) "" (make-table ["fred" "mary" "sally" "joan"] 2) On Mon, Feb 16, 2009 at 9:18 PM, Jesse Aldridge wrote: > > > I'm trying to port some Python code to Clojure. I'm new to functional > programming and I hit a function that is causing my brain to melt. > The python function looks something like this: > > > def build_table(): >num_cols = 3 >selected_row = 0 >selected_col = 0 >strings = ["cat", "dog", "", "rabbit", "frog", "elephant", > "gorilla"] > >row, col = 0, 0 >table_contents = "\n\n" >for string in strings: >if string == "": >continue > >if col >= num_cols: >row += 1 >col = 0 >table_contents += "\n" > >def new_cell(): >bg_color = "cfcfdf" >if(col == selected_col and row == selected_row): >bg_color = "d0e0ff" >return "" + \ > "" + string[0] + \ > "" + string[1:] + "\n" >table_contents += new_cell() > >col += 1 > >table_contents += "\n" >return table_contents > > If someone could please demonstrate how to do this in Clojure, I think > it would greatly help my understanding of the language and functional > programming in general. > > > --~--~-~--~~~---~--~~ 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 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 on CLR/DLR
Anything buy IronClojure. On Feb 16, 7:30 pm, Rich Hickey wrote: > On Feb 16, 2009, at 7:17 PM, dmiller wrote: > > > > > > > On Feb 16, 5:33 pm, Chouser wrote: > >> On Mon, Feb 16, 2009 at 5:43 PM, dmiller > >> wrote: > > >> I don't know if you've looked at ClojureScript at all, but it's a > >> similar if noticeably less ambitious project to compile Clojure > >> code to > >> JavaScript. It's in clojure-contrib already, but in > >> trunk/clojurescript instead of trunk/src. My reasons for this were > >> (1) I wasn't quite sure how to lay out the directory structure and > >> didn't want to mess up anyone else, and (2) it doesn't work with > >> Clojure trunk but instead requires a patch and rebuild of Clojure > >> itself. This patch is stored right there in contrib as well. > > > I have looked briefly at ClojureScript. > > > Placement: I'm guessing a parallel off-trunk placement. This code is > > completely independent of Clojure/JVM, except for the bootstrap *.clj > > files. I have those included in the project, so I'm not broken by > > Clojure/JVM changes. > > > Also, this code is not set up for casual play. You need to be in > > Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm > > thinking it should not be in trunk/src by the criteria you cite. > > >> This is the majority of what the ClojureScript patch changes -- > >> moving > >> explicit uses of non-Clojure Java class names out of .clj files and > >> into clojure.lang.RT (or other appropriate Clojure classes) so that > >> the .clj can be loaded as-is. RT and Numbers have to be ported by > >> hand anyway, so it's not significantly worse on that end. > > >> I'd be very interested to compare notes and see if our needs have a > >> common solution. > > > I need to make the same kinds of changes to the *.clj files. This has > > not been automated yet, so being in synch is a matter of hand- > > editing. > > > We most definitely need to compare notes. > > >> Sounds great! But there's one very important question you didn't > >> address. What are you going to call it? :-) > > >> Seriously, though, since it seems likely that a majority of code > >> written to run on your port will not work on Clojure/JVM, because of > >> the runtime libs available (please correct me if I'm wrong), it's > >> important for a body of code to be able to clearly declare where it's > >> supposed to work. A name that is used consistently can help, I would > >> think. > > > This is 100% C#/.NET. > > > I'm up for suggestions on the name. The obvious ones: > > > - Clojure.net > > - ClojureCLR > > - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron > > trademarked.) > > - CLjR (too cute) > > > Perhaps Rich will have a preference. He'll have to live with it > > longer than anyone and has branding/confusion issues to keep in mind. > > I prefer ClojureCLR. > > 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 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: How do I do this in clojure?
On Mon, Feb 16, 2009 at 9:18 PM, Jesse Aldridge wrote: > > > I'm trying to port some Python code to Clojure. I'm new to functional > programming and I hit a function that is causing my brain to melt. > The python function looks something like this: > > > def build_table(): >num_cols = 3 >selected_row = 0 >selected_col = 0 >strings = ["cat", "dog", "", "rabbit", "frog", "elephant", > "gorilla"] > >row, col = 0, 0 >table_contents = "\n\n" >for string in strings: >if string == "": >continue > >if col >= num_cols: >row += 1 >col = 0 >table_contents += "\n" > >def new_cell(): >bg_color = "cfcfdf" >if(col == selected_col and row == selected_row): >bg_color = "d0e0ff" >return "" + \ > "" + string[0] + \ > "" + string[1:] + "\n" >table_contents += new_cell() > >col += 1 > >table_contents += "\n" >return table_contents > > If someone could please demonstrate how to do this in Clojure, I think > it would greatly help my understanding of the language and functional > programming in general. > You should probably rework your Python logic too, you can make it a lot more concise and understandable: def make_table(cells, cols): spam = "" for i in xrange(0, len(cells), cols): spam += "" + "".join(cells[i:i+cols]) + " return "" + spam + "" --~--~-~--~~~---~--~~ 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 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 on CLR/DLR
On Mon, Feb 16, 2009 at 11:15 PM, Rayne wrote: > > Anything buy IronClojure. > > There's already an IronLisp anyway: http://www.codeplex.com/IronLisp --~--~-~--~~~---~--~~ 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 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: Newbie: Separating and grouping the elements in a bunch of vectors
On Mon, Feb 16, 2009 at 7:54 PM, samppi wrote: > > Thanks a lot, everyone. Isn't > (reduce conj [] (apply map vector [[:a :b] [1 2] ['a 'b]])) > equivalent to > (into [] (apply map vector [[:a :b] [1 2] ['a 'b]])) > though? Yes. --Chouser --~--~-~--~~~---~--~~ 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 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 on CLR/DLR
David, You have a great idea here with porting clojure to the CLR. The .NET shops are just a popular as Java shops, and something like this could go a long way to improving software written by a lot of people. Your initiative and hard work are to be commended. How do you plan on solving the library problem? As you mentioned, there are several discrepancies between .NET and Java libraries. Also, there will be applications written for a certain library that might only be available in one of the platforms. I know I have several .JARs that work with legacy applications ( like SAP & Oracle :) ) that I need to use. If some else needs to maintain them, I wouldn't want them to accidently try to run it on the wrong platform. If it can go wrong... Of course, this is a problem open source systems have had for a while, so it can be solved (apt,ASDF,rpm,rubygems...). It'll just take some work. Good work overall, I'm looking forward to what you come up with. On Feb 16, 7:17 pm, dmiller wrote: > On Feb 16, 5:33 pm, Chouser wrote: > > > On Mon, Feb 16, 2009 at 5:43 PM, dmiller wrote: > > > I don't know if you've looked at ClojureScript at all, but it's a > > similar if noticeably less ambitious project to compile Clojure code to > > JavaScript. It's in clojure-contrib already, but in > > trunk/clojurescript instead of trunk/src. My reasons for this were > > (1) I wasn't quite sure how to lay out the directory structure and > > didn't want to mess up anyone else, and (2) it doesn't work with > > Clojure trunk but instead requires a patch and rebuild of Clojure > > itself. This patch is stored right there in contrib as well. > > I have looked briefly at ClojureScript. > > Placement: I'm guessing a parallel off-trunk placement. This code is > completely independent of Clojure/JVM, except for the bootstrap *.clj > files. I have those included in the project, so I'm not broken by > Clojure/JVM changes. > > Also, this code is not set up for casual play. You need to be in > Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm > thinking it should not be in trunk/src by the criteria you cite. > > > This is the majority of what the ClojureScript patch changes -- moving > > explicit uses of non-Clojure Java class names out of .clj files and > > into clojure.lang.RT (or other appropriate Clojure classes) so that > > the .clj can be loaded as-is. RT and Numbers have to be ported by > > hand anyway, so it's not significantly worse on that end. > > > I'd be very interested to compare notes and see if our needs have a > > common solution. > > I need to make the same kinds of changes to the *.clj files. This has > not been automated yet, so being in synch is a matter of hand- > editing. > > We most definitely need to compare notes. > > > Sounds great! But there's one very important question you didn't > > address. What are you going to call it? :-) > > > Seriously, though, since it seems likely that a majority of code > > written to run on your port will not work on Clojure/JVM, because of > > the runtime libs available (please correct me if I'm wrong), it's > > important for a body of code to be able to clearly declare where it's > > supposed to work. A name that is used consistently can help, I would > > think. > > This is 100% C#/.NET. > > I'm up for suggestions on the name. The obvious ones: > > - Clojure.net > - ClojureCLR > - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron > trademarked.) > - CLjR (too cute) > > Perhaps Rich will have a preference. He'll have to live with it > longer than anyone and has branding/confusion issues to keep in mind. > > -- David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 on CLR/DLR
ClojureCLR it shall be. --dm On Feb 16, 7:30 pm, Rich Hickey wrote: > > I prefer ClojureCLR. > > 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 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 on CLR/DLR
Porting Clojure to the CLR is hardly an original idea. Rich started with dual JVM/CLR implementations. And inquiries have been made on this group any number of times. Regarding the library problem, I'm not exactly sure which problem you are referring to. Several things comes to mind. At the implementation level, there is the problem of loading the *.clj environment bootstrapping files. A common approach for Clojure, ClojureScript and ClojureCLR would push some JVM library calls in core.clj (for example) into RT. Type hints via tag metadata will require a more creative solution. Also, some Clojure API functions are JVM-specific and would need some modification. Those decisions are above my pay grade. At any rate, these problems should not surface to application programmers. At the application level, interop from .clj code with Clojure library classes should be portable because I've matched namespace/classname/ methodname pretty much across the board. If you have a lot of interop with JVM/CLR class libraries, I would imagine you would pick one and stick with it. In your example, if you have legacy JARs you need to interact with, you're in Clojure on the JVM. -- David On Feb 16, 10:50 pm, Sean wrote: > David, > You have a great idea here with porting clojure to the CLR. The .NET > shops are just a popular as Java shops, and something like this could > go a long way to improving software written by a lot of people. Your > initiative and hard work are to be commended. > > How do you plan on solving the library problem? As you mentioned, > there are several discrepancies between .NET and Java libraries. > Also, there will be applications written for a certain library that > might only be available in one of the platforms. I know I have > several .JARs that work with legacy applications ( like SAP & > Oracle :) ) that I need to use. If some else needs to maintain them, > I wouldn't want them to accidently try to run it on the wrong > platform. If it can go wrong... > > Of course, this is a problem open source systems have had for a while, > so it can be solved (apt,ASDF,rpm,rubygems...). It'll just take some > work. > > Good work overall, I'm looking forward to what you come up with. > > On Feb 16, 7:17 pm, dmiller wrote: > > > On Feb 16, 5:33 pm, Chouser wrote: > > > > On Mon, Feb 16, 2009 at 5:43 PM, dmiller wrote: > > > > I don't know if you've looked at ClojureScript at all, but it's a > > > similar if noticeably less ambitious project to compile Clojure code to > > > JavaScript. It's in clojure-contrib already, but in > > > trunk/clojurescript instead of trunk/src. My reasons for this were > > > (1) I wasn't quite sure how to lay out the directory structure and > > > didn't want to mess up anyone else, and (2) it doesn't work with > > > Clojure trunk but instead requires a patch and rebuild of Clojure > > > itself. This patch is stored right there in contrib as well. > > > I have looked briefly at ClojureScript. > > > Placement: I'm guessing a parallel off-trunk placement. This code is > > completely independent of Clojure/JVM, except for the bootstrap *.clj > > files. I have those included in the project, so I'm not broken by > > Clojure/JVM changes. > > > Also, this code is not set up for casual play. You need to be in > > Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm > > thinking it should not be in trunk/src by the criteria you cite. > > > > This is the majority of what the ClojureScript patch changes -- moving > > > explicit uses of non-Clojure Java class names out of .clj files and > > > into clojure.lang.RT (or other appropriate Clojure classes) so that > > > the .clj can be loaded as-is. RT and Numbers have to be ported by > > > hand anyway, so it's not significantly worse on that end. > > > > I'd be very interested to compare notes and see if our needs have a > > > common solution. > > > I need to make the same kinds of changes to the *.clj files. This has > > not been automated yet, so being in synch is a matter of hand- > > editing. > > > We most definitely need to compare notes. > > > > Sounds great! But there's one very important question you didn't > > > address. What are you going to call it? :-) > > > > Seriously, though, since it seems likely that a majority of code > > > written to run on your port will not work on Clojure/JVM, because of > > > the runtime libs available (please correct me if I'm wrong), it's > > > important for a body of code to be able to clearly declare where it's > > > supposed to work. A name that is used consistently can help, I would > > > think. > > > This is 100% C#/.NET. > > > I'm up for suggestions on the name. The obvious ones: > > > - Clojure.net > > - ClojureCLR > > - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron > > trademarked.) > > - CLjR (too cute) > > > Perhaps Rich will have a preference. He'll have to live with it > > longer than anyone and has branding/confusion issues
Re: How do I do this in clojure?
Alright, I got it working. Thanks for the replies. --~--~-~--~~~---~--~~ 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 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: Newbie: Separating and grouping the elements in a bunch of vectors
You're right, thanks ! 2009/2/17 Chouser > > On Mon, Feb 16, 2009 at 7:54 PM, samppi wrote: > > > > Thanks a lot, everyone. Isn't > > (reduce conj [] (apply map vector [[:a :b] [1 2] ['a 'b]])) > > equivalent to > > (into [] (apply map vector [[:a :b] [1 2] ['a 'b]])) > > though? > > Yes. > > --Chouser > > > > --~--~-~--~~~---~--~~ 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 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: How do I do this in clojure?
I found this question interesting for two reasons: (1) A selected item has been specified which needs to be handled differently - at first glance suggests an iterative solution. (2) There is good support for html in clojure via libraries, so you should avoid string concatenation of tags. So here is my solution: http://groups.google.com/group/clojure/web/layout.clj Notably it bolds the selected item without any iteration, and returns a list representation of the html instead of a string. I'm not familiar with the html libraries to render this representation so forgive any inconsistencies there, but the output is: (:table (:tr (:item (:bold "cat")) (:item "dog") (:item "")) (:tr (:item "rabbit") (:item "frog") (:item "elephant"))) Which will be validated by the rendering library, giving an additional security that it is correct. In order to deal with the 'selected item' I had to jump through some hoops to treat collections as vectors and use assoc on that. Is there perhaps a more elegant way? Overall though I hope it is a good example of how and why it is a good idea to avoid string catting and instead think of the problem in terms of creating a structure. Really you are building a tree based upon some inputs. I'd be interested in other ways the tree could be constructed. 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 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 -~--~~~~--~~--~--~---
Does this debugger feature exist?
Hi, I've just recently attached JSwat to Clojure and while it provides the functionality that I'm used to back when I was still writing Java code, it's not as streamlined to Clojure as I would like. I'm wondering if anything like this exists yet: A simple breakpoint and stepper, which halts the program when a breakpoint is hit, and globally binds the local variables currently in scope so that they can be investigated using the REPL. eg. I put a breakpoint in my clojure code, run it until it hits the breakpoint, and then examine the local variables using the REPL. I'm reading through SLIME's manual, and it sounds like they're might be this feature, but I'm not too sure. Thanks for the help -Patrick --~--~-~--~~~---~--~~ 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 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: Does this debugger feature exist?
I'm sure SLIME has similar features (I've used them with SBCL) but I haven't managed to get them to work with Clojure yet -- my suspicion is that they're not implemented in swank-clojure yet -- although I'll admit I haven't tried too hard. -Jason On Feb 16, 11:38 pm, CuppoJava wrote: > Hi, > I've just recently attached JSwat to Clojure and while it provides the > functionality that I'm used to back when I was still writing Java > code, it's not as streamlined to Clojure as I would like. > > I'm wondering if anything like this exists yet: > A simple breakpoint and stepper, which halts the program when a > breakpoint is hit, and globally binds the local variables currently in > scope so that they can be investigated using the REPL. > > eg. I put a breakpoint in my clojure code, run it until it hits the > breakpoint, and then examine the local variables using the REPL. > > I'm reading through SLIME's manual, and it sounds like they're might > be this feature, but I'm not too sure. > Thanks for the help > -Patrick --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
