Re: A DSL for writing scripts which have restricted memory and cpu usage
Yes and No but more No than Yes. If they can execute full Clojure, they can use all the memory they want. If they have the right to do a very small number of operation (building block for the program), you can limit the program they execute to those having those shape. But capping memory and CPU time is a quite hard static analysis to do. On Tue, Jul 13, 2010 at 7:29 AM, Heinz N. Gies wrote: > > On Jul 13, 2010, at 2:44 , Folcon wrote: > > > > > > > On Jul 13, 1:36 am, ngocdaothanh wrote: > >>> Are there any ways to restrict how many resources a user has access to? > >> > >> If you use Linux, you see /etc/security/limits.conf. > > > > That is useful and I will keep that in mind, however I was thinking of > > application users, so they would login to the clojure application and > > run scripts on it. Can they somehow be restricted? > > > > I will definitely consider running the app under a seperate user and > > putting limits on that user as a whole. > > Hi Falcon, > yes and no, you can limit CPU usage by limiting execution time. Limiting > memory usage of a specific code is hard at best and more goes towards the > impossible corner - sadly, I try to do this myself for clj-sandbox and fail > since about half a year :P. > > Regards, > Heinz > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A DSL for writing scripts which have restricted memory and cpu usage
On Tue, 13 Jul 2010 08:29:00 +0200 "Heinz N. Gies" wrote: > > On Jul 13, 2010, at 2:44 , Folcon wrote: > > > > > > > On Jul 13, 1:36 am, ngocdaothanh wrote: > >>> Are there any ways to restrict how many resources a user has access to? > >> > >> If you use Linux, you see /etc/security/limits.conf. > > > > That is useful and I will keep that in mind, however I was thinking of > > application users, so they would login to the clojure application and > > run scripts on it. Can they somehow be restricted? > > > > I will definitely consider running the app under a seperate user and > > putting limits on that user as a whole. > > Hi Falcon, > yes and no, you can limit CPU usage by limiting execution time. Limiting > memory usage of a specific code is hard at best and more goes towards the > impossible corner - sadly, I try to do this myself for clj-sandbox and fail > since about half a year :P. If you're on Linux, there's a sysctl you can use to cap the processes various memory usages. However, that's on a per-process basis, so if the user can fork, they can use more total memory than that. (Hmm - maybe there's a per-user limit as well...) Not sure how you get to sysctl's from the java world, though. If you're using Solaris, it has very good tools for limiting how much memory and/or CPU % a "project" can use, where projects can be pretty arbitrarily defined. If you're wanting to give people full access to clojure as part of the deal (a "try clojure online" type thing), then you can use solaris zones to create an environment that's isolated from the rest of your system and having a maximum percentage of CPU and memory available. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Atomic execution of a SELECT and UPDATE
Hi Sean, I think there are two ways to do this; 1) Use an agent. You can "send-off" a fn to the agent with your select/update logic and this will run within the agent thread - guaranteed to be serial so you only need your select/update and no retry logic. The state of the agent is not important - you could just keep some useful info from each call, or maybe the db connection. Just remember to return that as the last item of your fn. You also need to have an appropriate error handler - see (doc agent). Note also that the error handling for agents has changed for clojure 1.2. 2.) Use a traditional db transaction - select ... for update, commit or roll-back and try again. You could use clojure.contrib.sql or there are a few other clojure sql libraries available. I personally just use java interop with jdbc directly. Don't use refs or atoms as they are not suited to fn's that perform side-effects - because they could and will be executed more than once (even if the side-effect is the last step). They are for use with shared access to in-memory immutable structures. -Hth, Adrian. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A DSL for writing scripts which have restricted memory and cpu usage
Well I was thinking of providing a simplified subset of the language which be converted into clojure syntax and then executed, that way I would hopefully not give them the full power of the language, but they would still get a reasonable scripting language. Only the keywords that I choose would be executed as they would be all that was recognised by my reader. I wasn't considering running on a solaris although thank you for pointing that out. I personally find it odd that there aren't tools that can do the same in linux. How about a system where each user that is running a script gets a thread or thread pool, any script they run would be in that specific thread or thread pool. Can I limit that thread pool? I did a quick google and found clj-sandbox, http://github.com/Licenser/clj-sandbox. Any reason that wouldn't be sufficient? I'm a little worried when the code writer says he's failing in writing it. :S I'll need to poke around in it to see how it works. :) On Jul 13, 8:46 am, Mike Meyer wrote: > On Tue, 13 Jul 2010 08:29:00 +0200 > "Heinz N. Gies" wrote: > > > > > > > > > On Jul 13, 2010, at 2:44 , Folcon wrote: > > > > On Jul 13, 1:36 am, ngocdaothanh wrote: > > >>> Are there any ways to restrict how many resources a user has access to? > > > >> If you use Linux, you see /etc/security/limits.conf. > > > > That is useful and I will keep that in mind, however I was thinking of > > > application users, so they would login to the clojure application and > > > run scripts on it. Can they somehow be restricted? > > > > I will definitely consider running the app under a seperate user and > > > putting limits on that user as a whole. > > > Hi Falcon, > > yes and no, you can limit CPU usage by limiting execution time. Limiting > > memory usage of a specific code is hard at best and more goes towards the > > impossible corner - sadly, I try to do this myself for clj-sandbox and fail > > since about half a year :P. > > If you're on Linux, there's a sysctl you can use to cap the processes > various memory usages. However, that's on a per-process basis, so if > the user can fork, they can use more total memory than that. (Hmm - > maybe there's a per-user limit as well...) Not sure how you get to > sysctl's from the java world, though. > > If you're using Solaris, it has very good tools for limiting how much > memory and/or CPU % a "project" can use, where projects can be pretty > arbitrarily defined. If you're wanting to give people full access to > clojure as part of the deal (a "try clojure online" type thing), then > you can use solaris zones to create an environment that's isolated > from the rest of your system and having a maximum percentage of CPU > and memory available. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org- Hide quoted > text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Bug report: function metadata is broken
Hi,
I asked in the IRC channel about metadata on functions[1], and was
told that it's indeed possible in 1.2. I tried this at the REPL and
saw the following behavior (which looks like a bug):
user=> (defn ^{:foo "v1.0"} mfoo "mfoo docstring" [] (println "foo v1.0"))
#'user/mfoo
user=> (meta mfoo)
{:ns #, :name mfoo}
user=> (mfoo)
foo v1.0
nil
user=> (defn ^{:foo "v2.0"} mfoo "mfoo docstring" [] (println "foo v2.0"))
#'user/mfoo
user=> (meta mfoo)
{:ns #, :name mfoo, :file "NO_SOURCE_PATH", :line
33, :arglists ([]), :doc "mfoo docstring", :foo "v1.0"}
user=> (mfoo)
foo v2.0
nil
This is from the latest source:
$ git remote -v
originhttp://github.com/clojure/clojure.git (fetch)
originhttp://github.com/clojure/clojure.git (push)
$ git rev-parse HEAD
d184ed95817c5ddfd5874ea75e83e0df7e753c24
It appears I can't create new tickets on assembla[2], so I'm posting
to the mailing list instead.
Thanks!
Mike
[1] http://clojure-log.n01se.net/#04:25
[2] http://www.assembla.com/spaces/clojure/tickets
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Bug report: function metadata is broken
Hi,
On Jul 13, 11:52 am, Mike Mazur wrote:
> I asked in the IRC channel about metadata on functions[1], and was
> told that it's indeed possible in 1.2. I tried this at the REPL and
> saw the following behavior (which looks like a bug):
>
> user=> (defn ^{:foo "v1.0"} mfoo "mfoo docstring" [] (println "foo v1.0"))
> #'user/mfoo
> user=> (meta mfoo)
> {:ns #, :name mfoo}
> user=> (mfoo)
> foo v1.0
> nil
> user=> (defn ^{:foo "v2.0"} mfoo "mfoo docstring" [] (println "foo v2.0"))
> #'user/mfoo
> user=> (meta mfoo)
> {:ns #, :name mfoo, :file "NO_SOURCE_PATH", :line
> 33, :arglists ([]), :doc "mfoo docstring", :foo "v1.0"}
> user=> (mfoo)
> foo v2.0
> nil
Metadata on functions works as expected:
user=> (meta (with-meta (fn [] :with-meta) {:foo "v1.0"}))
{:foo "v1.0"}
Hinting the argument to defn (or providing the optional meta map)
attaches the metadata to the Var:
user=> (defn ^{:mfoo "v1.0"} mfoo "mfoo docstring" {:foo "v1.0"} []
(println "foo v1.0"))
#'user/mfoo
user=> (meta #'mfoo)
{:ns #, :name mfoo, :file "NO_SOURCE_PATH", :line
1, :arglists ([]), :foo "v1.0", :doc "mfoo docstring", :mfoo "v1.0"}
user=> (meta mfoo)
{:ns #, :name mfoo}
I'm not sure, though, why the metadata gets moved to the function on
redefinition.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: terracotta?
I have not pursued any further work with Terracotta, because I haven't had a real project that required it. I'd be glad to try to pick something back up, especially if there are others interested in helping out. Paul http://paul.stadig.name/ (blog) 703-634-9339 (mobile) pjstadig (twitter) p...@stadig.name (jabber) Projects http://www.mycrossoverpoint.com/ http://www.reformedchurches.info/ On Mon, Jul 12, 2010 at 4:36 AM, peter veentjer wrote: > I don't think it every is going to scale. > > MVCC/TL2 based STM designs rely on a central clock, so if you can > update the clock in 0.1 ms on all machines, the maximum throughput is > 1/0.0001 = 10.000 transactions/second... no matter how many machines > you throw at it. Even on a single machine the central clock can cause > scalability problems (10/20M transactions/second and this will degrade > when you throw more cores at it). > > This is one of the reasons I dropped the TL2 approach for Multiverse > and switched over to the SkySTM model (with some magic of my own) that > doesn't relied as much on a central mechanism. > > On Jul 11, 6:50 pm, scx wrote: > > hi -- > > > > i've seen paul standig's work with clojure + terracotta. wondering if > > anyone has continued his 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 > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: alter atom while iterating
On Sun, Jul 11, 2010 at 9:24 PM, Jeffrey Schwab wrote:
> On 7/11/10 9:08 PM, Michał Marczyk wrote:
>>
>> On 12 July 2010 02:37, Jeffrey Schwab wrote:
>>>
>>> I did not know whether the sequence expressions (the right halves of the
>>> binding-forms) were evaluated strictly, or re-evaluated on each pass
>>> (like
>>> the body-expr). They are apparently evaluated a priori, when the
>>> comprehension is defined:
>>
>> Actually the example I posted previously demonstrates that this is not
>> the case. Here's another one:
>>
>> user=> (def a (atom #{1 2}))
>> #'user/a
>> user=> (def f (for [i (range 2) j @a] [i j]))
>> #'user/f
>> user=> (swap! a disj 1 2)
>> #{}
>> user=> f
>> ()
>>
>> ...whereas without the intervening swap!...
>>
>> user=> f
>> ([0 1] [0 2] [1 1] [1 2])
>>
>> Only the outermost expression is evaluated up front.
>
> Wow, that's non-intuitive. Thanks!
Well, the behavior you're seeing there is because 'for' is lazy,
and none of the seq expressions is evaluated until the REPL is
asked to print 'f'.
Perhaps this would clear things up some:
(defn r [i]
(println (format "" i))
(range i))
(for [a (r 2), b (r 3)] [a b])
; produces:
(
[0 0] [0 1]
[0 2] [1 0] [1 1] [1 2])
So just before seq is needed, the expression that produces that
seq is re-evaluated. This is necessary because inner seq
expressions to the right can refer to locals defined further to
the left, thus their result could be different for each
iteration:
(for [a (range 4), b (range (inc a))] [a b])
; produces, after formatting for clarity:
([0 0]
[1 0] [1 1]
[2 0] [2 1] [2 2]
[3 0] [3 1] [3 2] [3 3])
Hope that helps,
--Chouser
http://joyofclojure.com/
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
On 13 Jul, 01:28, j-g-faustus wrote: > On Jul 13, 12:25 am, j-g-faustus wrote: > > > I made my own cheat sheet for private use over the past month or so, > > core functions only. It's at the 80% stage, I don't expect it will > > ever be 100%, but I have found it useful: > > http://faustus.webatu.com/clj-quick-ref.html > > Looks like the hosting provider put my Clojure cheat sheet under > review, I guess they found it suspicious... :) It seems to have passed approval, so it is available again. In the context of this thread, the cheat sheet is primarily an argument on how to best structure the information. Personally I like the compact format of having categories, names, description and examples all on the same page (to the extent that a 6k line page can be called 'compact'), perhaps combined with links to more extensive documentation. YMMV, and I'm not sure if the format can be made to scale to the scope and community nature of ClojureDocs. But some form of categorization would be nice. jf -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: faster flatten?
Hi Cam,
Your tests aren't testing the interesting part without a doall.
That said, my quick tests with doall show your approach faring even better. :-)
Also, I think what my-flatten does with Java arrays is intuitive (and the
current flatten not so much).
A patch that preserves the semantics of the existing flatten (except for
working with Java arrays) would be welcome.
Thanks!
Stu
> Another flatten thread! Sorry..
>
> Hello all, before I realized there was a flatten in the master branch
> (and before I looked at contrib) I wrote this pretty standard code:
>
> (defn my-flatten [coll]
> (lazy-seq
> (when-let [coll (seq coll)]
> (let [x (first coll)]
> (if (sequential? x)
> (concat (my-flatten x) (my-flatten (next coll)))
> (cons x (my-flatten (next coll
>
> (There's very similar versions on the boards. I'm not claiming this is
> anything amazing or unique.)
>
> It's not as elegant as what's in core, but in my micro benchmarks (ran
> on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
> better, _especially_ in the already flattened case. It behaves just
> like core/flatten except that it doesn't return an empty list when
> passed a map or set, it just returns whatever you gave it but with the
> top level converted to a seq. I'm pretty much a clojure noob, so are
> there any hidden detractors of this implementation as opposed to the
> version introduced in 1.2?
>
> Also, quick note, if you swap the call to sequential? with seqable?
> from contrib/core, it flattens maps and sets like you'd expect as
> well.
> Here is how it looks
> user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
> (1 2 3 4 5 6 7 9 10 8)
>
> And for the micro-benchmarks (using "sequential?"):
>
> user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
> "Elapsed time: 14,661.592 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
> "Elapsed time: 922.268 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
> [[[9]]] 10 [11] 12 [13 14 [15])))
> "Elapsed time: 18,147.959 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
> [[[9]]] 10 [11] 12 [13 14 [15])))
> "Elapsed time: 6,088.914 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
> "Elapsed time: 11,696.693 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
> "Elapsed time: 1,533.983 msecs"
> nil
>
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: DataLog
I am new to clojure but learning quickly. I haven't yet tried clojure.contrib.Datalog, but I analyze big data and I can say that I quite like Nathan Marz's Cascalog. Cascalog is reminiscent of datalog syntax but executes queries on Hadoop via Cascading for data that is too big to fit in memory. (When data sets do fit in memory, I tend to use R.) So far I've been able to run queries against large files residing in Amazon's S3 using Cascalog. The next step is to compile a project with Cascalog and Incanter together via leiningen to visualize the output. I may need to lurk a bit on freenode to get that repl to compile, we'll see... Cascalog link: http://github.com/nathanmarz/cascalog Cheers, ~A On Jul 12, 7:02 pm, Wilson MacGyver wrote: > Has anyone used clojure.contrib.Datalog for anything serious? What > kind of problem > did you run into if any? > > What is the performance like? Is there a sweet spot beyond that it's > completely > in memory only? > > Thanks, > > -- > Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Stepping, debugging in REPL
I just made this debugger. It works but is still a bit rough around the edges. I'd be happy to hear your feedback. http://code.google.com/p/taskberry/wiki/Stepl -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: CCW zombie error markers
2010/7/12 Lee Spector > > Thanks Laurent. > > FWIW I had looked for the ccw-specific mailing list but not found it... > perhaps that should be advertised a bit more (e.g. I don't see it mentioned > on http://code.google.com/p/counterclockwise/). Thanks for pointing it out > to me. > It's under the menu entry named "Group". Not something I can change, it's the standard way of google code of naming things. You're not the first person having problems with that. Hmm, added a link in the central page > > On the specific issue: I had turned off "build automatically" because I > preferred to be able to save without triggering anything else. Maybe that > contributed to the problem. However, Project > Clean did NOT resolve the > problem by itself. The most recent instance of the problem DID clear up, > however, after clicking the "Remove Launch" and/or "Remove All Terminated > Launches" buttons above the REPL. I have no idea what those things really > mean (what's a launch anyway, and what's it being removed from?), but in my > desperate clicking I tried them and the zombie markers went away. > Weird. In Eclipse "terminology", when you want to "run" the content of the project, you "run" it by "launching" a "launch configuration". For a java project, a launch configuration typically stores what is on the classpath (initially derived from the project's java dependencies), plus it stores the name of the main class, plus the argument lines for the JVM, plus the argument lines for the program itself. You find all the launch configurations via the "Run > Run as ..." menu. A CCW "launch configuration" is basically a java launch configuration (reuses 90% of a standard java launch configuration behaviour), plus some clojure specific stuff in the main launch configuration tab: do we install a "repl server" in the launched configuration ? Which files do you want to be automatically loaded at startup ? To which port should the "repl server" listen ? etc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: cache dot clj - caching impure functions
Dear all,
I had the time to clean up my code.
It's quite similar to your lib but it uses google-collections and so
ConcurrentHashMap instead of (atom {}), which should allow more concurrency.
I am a bit annoyed with the semantic of google-collections MapMaker as it
does not allow soft keys with equals as an equality.
It prevents me from doing a version of this lib without using the delay
operator, which would be less effect-safe but a bit faster.
I might try to reimplement this, using the ConcurrentMaps of jsr166yextra,
which seems a bit better.
Anyway, I think it is usable even if it has not been much tested (so, of
course, not production ready).
https://nicolasoury.repositoryhosting.com/trac/nicolasoury_cached-google-collections/wiki
Comments, suggestions, and the like are more than welcome.
Best regards.
Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: faster flatten?
Hi Stuart,
Thanks for checking that out for me! Sorry for not realizing in the
first place.
I of course would be happy to submit a patch. Should I submit that
here or over on the assembla page?
On Jul 13, 9:10 am, Stuart Halloway wrote:
> Hi Cam,
>
> Your tests aren't testing the interesting part without a doall.
>
> That said, my quick tests with doall show your approach faring even better.
> :-) Also, I think what my-flatten does with Java arrays is intuitive (and the
> current flatten not so much).
>
> A patch that preserves the semantics of the existing flatten (except for
> working with Java arrays) would be welcome.
>
> Thanks!
> Stu
>
>
>
> > Another flatten thread! Sorry..
>
> > Hello all, before I realized there was a flatten in the master branch
> > (and before I looked at contrib) I wrote this pretty standard code:
>
> > (defn my-flatten [coll]
> > (lazy-seq
> > (when-let [coll (seq coll)]
> > (let [x (first coll)]
> > (if (sequential? x)
> > (concat (my-flatten x) (my-flatten (next coll)))
> > (cons x (my-flatten (next coll
>
> > (There's very similar versions on the boards. I'm not claiming this is
> > anything amazing or unique.)
>
> > It's not as elegant as what's in core, but in my micro benchmarks (ran
> > on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
> > better, _especially_ in the already flattened case. It behaves just
> > like core/flatten except that it doesn't return an empty list when
> > passed a map or set, it just returns whatever you gave it but with the
> > top level converted to a seq. I'm pretty much a clojure noob, so are
> > there any hidden detractors of this implementation as opposed to the
> > version introduced in 1.2?
>
> > Also, quick note, if you swap the call to sequential? with seqable?
> > from contrib/core, it flattens maps and sets like you'd expect as
> > well.
> > Here is how it looks
> > user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
> > (1 2 3 4 5 6 7 9 10 8)
>
> > And for the micro-benchmarks (using "sequential?"):
>
> > user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
> > "Elapsed time: 14,661.592 msecs"
> > nil
>
> > user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
> > "Elapsed time: 922.268 msecs"
> > nil
>
> > user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
> > [[[9]]] 10 [11] 12 [13 14 [15])))
> > "Elapsed time: 18,147.959 msecs"
> > nil
>
> > user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
> > [[[9]]] 10 [11] 12 [13 14 [15])))
> > "Elapsed time: 6,088.914 msecs"
> > nil
>
> > user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
> > "Elapsed time: 11,696.693 msecs"
> > nil
>
> > user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
> > "Elapsed time: 1,533.983 msecs"
> > nil
>
> > Thoughts?
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: faster flatten?
Hi Cam,
The full instructions for joining the team and then submitting a patch are at
[1] an [2], but in short:
* send in a CA
* join the Assembla space under you real name
* post a patch there linking to this thread
Thanks!
Stu
[1] http://clojure.org/contributing
[2] http://clojure.org/patches
> Hi Stuart,
>
> Thanks for checking that out for me! Sorry for not realizing in the
> first place.
>
> I of course would be happy to submit a patch. Should I submit that
> here or over on the assembla page?
>
> On Jul 13, 9:10 am, Stuart Halloway wrote:
>> Hi Cam,
>>
>> Your tests aren't testing the interesting part without a doall.
>>
>> That said, my quick tests with doall show your approach faring even better.
>> :-) Also, I think what my-flatten does with Java arrays is intuitive (and
>> the current flatten not so much).
>>
>> A patch that preserves the semantics of the existing flatten (except for
>> working with Java arrays) would be welcome.
>>
>> Thanks!
>> Stu
>>
>>
>>
>>> Another flatten thread! Sorry..
>>
>>> Hello all, before I realized there was a flatten in the master branch
>>> (and before I looked at contrib) I wrote this pretty standard code:
>>
>>> (defn my-flatten [coll]
>>> (lazy-seq
>>> (when-let [coll (seq coll)]
>>> (let [x (first coll)]
>>> (if (sequential? x)
>>> (concat (my-flatten x) (my-flatten (next coll)))
>>> (cons x (my-flatten (next coll
>>
>>> (There's very similar versions on the boards. I'm not claiming this is
>>> anything amazing or unique.)
>>
>>> It's not as elegant as what's in core, but in my micro benchmarks (ran
>>> on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
>>> better, _especially_ in the already flattened case. It behaves just
>>> like core/flatten except that it doesn't return an empty list when
>>> passed a map or set, it just returns whatever you gave it but with the
>>> top level converted to a seq. I'm pretty much a clojure noob, so are
>>> there any hidden detractors of this implementation as opposed to the
>>> version introduced in 1.2?
>>
>>> Also, quick note, if you swap the call to sequential? with seqable?
>>> from contrib/core, it flattens maps and sets like you'd expect as
>>> well.
>>> Here is how it looks
>>> user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
>>> (1 2 3 4 5 6 7 9 10 8)
>>
>>> And for the micro-benchmarks (using "sequential?"):
>>
>>> user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
>>> "Elapsed time: 14,661.592 msecs"
>>> nil
>>
>>> user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
>>> "Elapsed time: 922.268 msecs"
>>> nil
>>
>>> user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
>>> [[[9]]] 10 [11] 12 [13 14 [15])))
>>> "Elapsed time: 18,147.959 msecs"
>>> nil
>>
>>> user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
>>> [[[9]]] 10 [11] 12 [13 14 [15])))
>>> "Elapsed time: 6,088.914 msecs"
>>> nil
>>
>>> user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
>>> "Elapsed time: 11,696.693 msecs"
>>> nil
>>
>>> user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
>>> "Elapsed time: 1,533.983 msecs"
>>> nil
>>
>>> Thoughts?
>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: faster flatten?
Hi again, I modified my-flatten to return the empty list for sets and
maps as core/flatten does. It doesn't seem to handle Arrays anymore
though. I'm assuming it's because ArrayList and (int-array ...) don't
implement Sequential. None the less should I still submit this
modified version that behaves just like core/flatten?
(defn my-flatten
[coll]
(lazy-seq
(when-let [coll (if (sequential? coll) (seq coll))]
(let [x (first coll)]
(if (sequential? x)
(concat (my-flatten x) (my-flatten (next coll)))
(cons x (my-flatten (next coll
Might it be worth promoting "seqable?" to core? In that case flatten
would handle pretty much everything you could throw at it like you'd
expect. I don't speak for everyone but when I saw sequential? I
assumed it would have the semantics that seqable? does.
On Jul 13, 11:04 am, Cam wrote:
> Hi Stuart,
>
> Thanks for checking that out for me! Sorry for not realizing in the
> first place.
>
> I of course would be happy to submit a patch. Should I submit that
> here or over on the assembla page?
>
> On Jul 13, 9:10 am, Stuart Halloway wrote:
>
>
>
> > Hi Cam,
>
> > Your tests aren't testing the interesting part without a doall.
>
> > That said, my quick tests with doall show your approach faring even better.
> > :-) Also, I think what my-flatten does with Java arrays is intuitive (and
> > the current flatten not so much).
>
> > A patch that preserves the semantics of the existing flatten (except for
> > working with Java arrays) would be welcome.
>
> > Thanks!
> > Stu
>
> > > Another flatten thread! Sorry..
>
> > > Hello all, before I realized there was a flatten in the master branch
> > > (and before I looked at contrib) I wrote this pretty standard code:
>
> > > (defn my-flatten [coll]
> > > (lazy-seq
> > > (when-let [coll (seq coll)]
> > > (let [x (first coll)]
> > > (if (sequential? x)
> > > (concat (my-flatten x) (my-flatten (next coll)))
> > > (cons x (my-flatten (next coll
>
> > > (There's very similar versions on the boards. I'm not claiming this is
> > > anything amazing or unique.)
>
> > > It's not as elegant as what's in core, but in my micro benchmarks (ran
> > > on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
> > > better, _especially_ in the already flattened case. It behaves just
> > > like core/flatten except that it doesn't return an empty list when
> > > passed a map or set, it just returns whatever you gave it but with the
> > > top level converted to a seq. I'm pretty much a clojure noob, so are
> > > there any hidden detractors of this implementation as opposed to the
> > > version introduced in 1.2?
>
> > > Also, quick note, if you swap the call to sequential? with seqable?
> > > from contrib/core, it flattens maps and sets like you'd expect as
> > > well.
> > > Here is how it looks
> > > user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
> > > (1 2 3 4 5 6 7 9 10 8)
>
> > > And for the micro-benchmarks (using "sequential?"):
>
> > > user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
> > > "Elapsed time: 14,661.592 msecs"
> > > nil
>
> > > user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
> > > "Elapsed time: 922.268 msecs"
> > > nil
>
> > > user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
> > > [[[9]]] 10 [11] 12 [13 14 [15])))
> > > "Elapsed time: 18,147.959 msecs"
> > > nil
>
> > > user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
> > > [[[9]]] 10 [11] 12 [13 14 [15])))
> > > "Elapsed time: 6,088.914 msecs"
> > > nil
>
> > > user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
> > > "Elapsed time: 11,696.693 msecs"
> > > nil
>
> > > user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
> > > "Elapsed time: 1,533.983 msecs"
> > > nil
>
> > > Thoughts?
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: faster flatten?
Hi Cam,
Please submit the modified version, and, if you want, create a separate ticket
for "seqable?". I would like to review the latter separately.
Stu
> Hi again, I modified my-flatten to return the empty list for sets and
> maps as core/flatten does. It doesn't seem to handle Arrays anymore
> though. I'm assuming it's because ArrayList and (int-array ...) don't
> implement Sequential. None the less should I still submit this
> modified version that behaves just like core/flatten?
>
> (defn my-flatten
> [coll]
> (lazy-seq
>(when-let [coll (if (sequential? coll) (seq coll))]
> (let [x (first coll)]
>(if (sequential? x)
> (concat (my-flatten x) (my-flatten (next coll)))
> (cons x (my-flatten (next coll
>
> Might it be worth promoting "seqable?" to core? In that case flatten
> would handle pretty much everything you could throw at it like you'd
> expect. I don't speak for everyone but when I saw sequential? I
> assumed it would have the semantics that seqable? does.
>
>
> On Jul 13, 11:04 am, Cam wrote:
>> Hi Stuart,
>>
>> Thanks for checking that out for me! Sorry for not realizing in the
>> first place.
>>
>> I of course would be happy to submit a patch. Should I submit that
>> here or over on the assembla page?
>>
>> On Jul 13, 9:10 am, Stuart Halloway wrote:
>>
>>
>>
>>> Hi Cam,
>>
>>> Your tests aren't testing the interesting part without a doall.
>>
>>> That said, my quick tests with doall show your approach faring even better.
>>> :-) Also, I think what my-flatten does with Java arrays is intuitive (and
>>> the current flatten not so much).
>>
>>> A patch that preserves the semantics of the existing flatten (except for
>>> working with Java arrays) would be welcome.
>>
>>> Thanks!
>>> Stu
>>
Another flatten thread! Sorry..
>>
Hello all, before I realized there was a flatten in the master branch
(and before I looked at contrib) I wrote this pretty standard code:
>>
(defn my-flatten [coll]
(lazy-seq
(when-let [coll (seq coll)]
(let [x (first coll)]
(if (sequential? x)
(concat (my-flatten x) (my-flatten (next coll)))
(cons x (my-flatten (next coll
>>
(There's very similar versions on the boards. I'm not claiming this is
anything amazing or unique.)
>>
It's not as elegant as what's in core, but in my micro benchmarks (ran
on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
better, _especially_ in the already flattened case. It behaves just
like core/flatten except that it doesn't return an empty list when
passed a map or set, it just returns whatever you gave it but with the
top level converted to a seq. I'm pretty much a clojure noob, so are
there any hidden detractors of this implementation as opposed to the
version introduced in 1.2?
>>
Also, quick note, if you swap the call to sequential? with seqable?
from contrib/core, it flattens maps and sets like you'd expect as
well.
Here is how it looks
user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
(1 2 3 4 5 6 7 9 10 8)
>>
And for the micro-benchmarks (using "sequential?"):
>>
user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
"Elapsed time: 14,661.592 msecs"
nil
>>
user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
"Elapsed time: 922.268 msecs"
nil
>>
user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
[[[9]]] 10 [11] 12 [13 14 [15])))
"Elapsed time: 18,147.959 msecs"
nil
>>
user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
[[[9]]] 10 [11] 12 [13 14 [15])))
"Elapsed time: 6,088.914 msecs"
nil
>>
user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
"Elapsed time: 11,696.693 msecs"
nil
>>
user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
"Elapsed time: 1,533.983 msecs"
nil
>>
Thoughts?
>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message becaus
Re: faster flatten?
OK, all submitted. The tickets are up for discussion at
http://www.assembla.com/spaces/clojure/support/tickets/400-a-faster-flatten
http://www.assembla.com/spaces/clojure/support/tickets/401-promote--seqable---from-contrib-
I will mail my CA in tomorrow morning.
Thanks Stu and Mark!
On Jul 13, 11:57 am, Stuart Halloway
wrote:
> Hi Cam,
>
> Please submit the modified version, and, if you want, create a separate
> ticket for "seqable?". I would like to review the latter separately.
>
> Stu
>
>
>
> > Hi again, I modified my-flatten to return the empty list for sets and
> > maps as core/flatten does. It doesn't seem to handle Arrays anymore
> > though. I'm assuming it's because ArrayList and (int-array ...) don't
> > implement Sequential. None the less should I still submit this
> > modified version that behaves just like core/flatten?
>
> > (defn my-flatten
> > [coll]
> > (lazy-seq
> > (when-let [coll (if (sequential? coll) (seq coll))]
> > (let [x (first coll)]
> > (if (sequential? x)
> > (concat (my-flatten x) (my-flatten (next coll)))
> > (cons x (my-flatten (next coll
>
> > Might it be worth promoting "seqable?" to core? In that case flatten
> > would handle pretty much everything you could throw at it like you'd
> > expect. I don't speak for everyone but when I saw sequential? I
> > assumed it would have the semantics that seqable? does.
>
> > On Jul 13, 11:04 am, Cam wrote:
> >> Hi Stuart,
>
> >> Thanks for checking that out for me! Sorry for not realizing in the
> >> first place.
>
> >> I of course would be happy to submit a patch. Should I submit that
> >> here or over on the assembla page?
>
> >> On Jul 13, 9:10 am, Stuart Halloway wrote:
>
> >>> Hi Cam,
>
> >>> Your tests aren't testing the interesting part without a doall.
>
> >>> That said, my quick tests with doall show your approach faring even
> >>> better. :-) Also, I think what my-flatten does with Java arrays is
> >>> intuitive (and the current flatten not so much).
>
> >>> A patch that preserves the semantics of the existing flatten (except for
> >>> working with Java arrays) would be welcome.
>
> >>> Thanks!
> >>> Stu
>
> Another flatten thread! Sorry..
>
> Hello all, before I realized there was a flatten in the master branch
> (and before I looked at contrib) I wrote this pretty standard code:
>
> (defn my-flatten [coll]
> (lazy-seq
> (when-let [coll (seq coll)]
> (let [x (first coll)]
> (if (sequential? x)
> (concat (my-flatten x) (my-flatten (next coll)))
> (cons x (my-flatten (next coll
>
> (There's very similar versions on the boards. I'm not claiming this is
> anything amazing or unique.)
>
> It's not as elegant as what's in core, but in my micro benchmarks (ran
> on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
> better, _especially_ in the already flattened case. It behaves just
> like core/flatten except that it doesn't return an empty list when
> passed a map or set, it just returns whatever you gave it but with the
> top level converted to a seq. I'm pretty much a clojure noob, so are
> there any hidden detractors of this implementation as opposed to the
> version introduced in 1.2?
>
> Also, quick note, if you swap the call to sequential? with seqable?
> from contrib/core, it flattens maps and sets like you'd expect as
> well.
> Here is how it looks
> user=> (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
> (1 2 3 4 5 6 7 9 10 8)
>
> And for the micro-benchmarks (using "sequential?"):
>
> user=> (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
> "Elapsed time: 14,661.592 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
> "Elapsed time: 922.268 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
> [[[9]]] 10 [11] 12 [13 14 [15])))
> "Elapsed time: 18,147.959 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
> [[[9]]] 10 [11] 12 [13 14 [15])))
> "Elapsed time: 6,088.914 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
> "Elapsed time: 11,696.693 msecs"
> nil
>
> user=> (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
> "Elapsed time: 1,533.983 msecs"
> nil
>
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
Re: ClojureDocs.org
On 12 July 2010 23:25, j-g-faustus wrote: > The site looks very nice, I especially like the "find real world > examples" functionality and the fact that it collects documentation > for common non-core libraries as well. > > I made my own cheat sheet for private use over the past month or so, > core functions only. It's at the 80% stage, I don't expect it will > ever be 100%, but I have found it useful: > http://faustus.webatu.com/clj-quick-ref.html Can I suggest omitting the "Table of contents" sidebar when printing? I've not tried printing the document to see how it looks, but removing the sidebar would be an essential starting point... Paul. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
I agree. The in-code function documentation serves its purpose but could be improved upon in a medium where space is at less of a premium. Bill Smith Austin, TX On Jul 10, 12:36 pm, James Reeves wrote: > On 10 July 2010 15:06, Stuart Halloway wrote: > > > (6) Because docstrings are designed for consumption at a REPL, they may in > > some cases presume a fixed font. Worth considering for display on the site. > > What about giving function documentation the same "wiki" behaviour > that the examples have? Start off with the docstrings as the initial > values, but allow people to update them. The web allows longer and > better formatted documentation than a standard Clojure docstring > (which needs to fit in a terminal). > > - 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN: Deview - Better test results
Hello Group. Another child (aleph being the other) of the June Bay Area Clojure Meetup. At the meetup, George Jahad presented difform; a tool for displaying the diff of two forms. I decided to take this to the next level. Deview is a tool for running tests in Leiningen projects which use clojure.test. Test results are much better than plain text. Any exception, either at compile time or in a test failure, is filtered using clj-stacktrace. For other failures a diff of the two forms is displayed. I hope someone else finds this as useful as I do. Blog post: http://formpluslogic.blogspot.com/2010/07/better-clojure-test-results-with-deview.html The project: http://github.com/brentonashworth/deview Brenton -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
Hi,
Am 13.07.2010 um 14:26 schrieb j-g-faustus:
>>> I made my own cheat sheet for private use over the past month or so,
>>> core functions only. It's at the 80% stage, I don't expect it will
>>> ever be 100%, but I have found it useful:
>>> http://faustus.webatu.com/clj-quick-ref.html
Some comments after quickly skimming through:
next vs. rest: neither of those two „more“ idiomatic. They are just different.
next will realise the next element of the sequence (of any), while rest will
not. So in general you want rest, but sometimes next is useful, eg. in a loop:
(loop [s (seq s)] (when s (do-something) (recur (next s))).
Your comment on sequence is wrong: sequence and seq are – like rest and next –
two different things. It's not that sequence was the „old“ seq.
replicate is a relic from the time where repeat didn't have an optional n.
Your examples on transients are wrong. You have to capture the return value of
the bang! functions as you would do with the non-bang versions. That
(persistent! tm) works in your examples is an implementation detail.
condp has another form, which could be mentioned because it is not widely known:
user=> (condp some [1 2 3]
#{2 4 6} :>> inc
#{3 5 7} :>> dec)
3
recur recurs not only to the function, but also to the same arity. So (fn ([a]
(println a)) ([a b] (recur (+ a b does not work.
extends? does check whether (extend ...) was called on a protocol with the
given type. This can be a Java class or something defined with with
deftype/defrecord. However for the latter not when the protocol methods where
specified inline.
io! is inside the transaction, but can be defined outside. (defn fn-with-io []
(io! (do-stuff))) . (dosync (fn-with-io)) <- exception
You might want to mention #_ in the comments section. It is a reader macro
which drops the following read thing. Useful to comment out code without
messing with the parens.
user=> [1 2 #_ 3]
[1 2]
In the require example: specifying :reload in an ns declaration smells.
You can also use :as with :use. (ns foo.bar (:use [frob.nicator :only
(defflogistionreactor) :as frobber])). Can be useful at times.
I don't like your use of '(quote lists) everywhere. Please use vectors. They
are the idiomatic answer of Clojure to quoted lists. Use quoted lists only
where it is interesting to distinguish the list from the vector, eg. in (vec
'(1 2 3)). (Related: if you find yourself quoting symbols, this means you
should use backquote because your are writing a macro or you should actually
use keywords.)
I really like your examples! They are simple, easy to understand, demonstrate
edge cases and focus on the thing being demonstrated. Two thumbs up.
Hope that helps.
Sincerely
Meikel
PS: I'm apologise if some this seems to be nit-picking.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Executable clojure scripts (#!/usr/bin/env clj)
I'm new to Clojure, and I've found it possible to make Clojure scripts executable by adding '#!/usr/bin/env clj' as the first line (and 'chmod +x' of course). E.g. My sample script: #!/usr/bin/env clj (println "Hello World") This seems like a very convenient way to dabble with Clojure, yet I have not seen it suggested anywhere. Is this method discouraged? -- Paul Richards @pauldoo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Executable clojure scripts (#!/usr/bin/env clj)
On Tue, 13 Jul 2010 21:55:15 +0100 Paul Richards wrote: > I'm new to Clojure, and I've found it possible to make Clojure scripts > executable by adding '#!/usr/bin/env clj' as the first line (and > 'chmod +x' of course). > > E.g. My sample script: > > #!/usr/bin/env clj > > (println "Hello World") > > This seems like a very convenient way to dabble with Clojure, yet I > have not seen it suggested anywhere. Is this method discouraged? It's just slow - you have to load the JVM, then clojure, then it starts working on your scripts. You can use nailgun to fix most of that. See my writeup on clojure without the Java (which also recommends the env hack) for more on that - and other such tricks.: http://www.mired.org/home/mwm/papers/simple-clojure.html http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
On 11 July 2010 12:05, Lukasz Urbanek wrote: > Looks very nice! > > Hoping for the categories to arrive to the core namespace. This really > saves a lot of time for a clojure beginner like me. +1 > Additionally, I'd prefer if the source was wasn't exposed by default > (It's quite distracting when one is looking for the examples), some > kind of "source" button that reveals it would be cool. +1 - I agree with others that people should be encouraged to program to the API, not the implementation. However sometimes its nice to be able to see the nitty gritty, so having a reveal source link would be great, without distracting from the more common case. R. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
On Jul 13, 8:37 pm, Paul Moore wrote: > Can I suggest omitting the "Table of contents" sidebar when printing? > I've not tried printing the document to see how it looks, but removing > the sidebar would be an essential starting point... Why would anyone want to print it? I occasionally print longer texts like specifications, but for reference material like Javadoc, ClojureDocs, the Ruby cheat sheet and this page, I think HTML is a far superior format due to links and browser search. And 40+ loose single sheets is a rather cumbersome package unless you have access to a book binder. But if at least two people feel that they would really like to print it out, I can skip the TOC on print. (Making it look _nice_ on paper is a whole different ballgame, then I'd have to look into pagination and page layouts, perhaps by converting to DocBook or LaTex. That's outside the scope of what I intended to do.) On Jul 13, 10:04 pm, Meikel Brandmeyer wrote: > Some comments after quickly skimming through: > ... > PS: I'm apologise if some this seems to be nit-picking. Not at all, I'm still learning the language and happy to get the details clarified. The second form of condp and the #_ were omitted simply because I didn't know about them, thanks for the heads-up. For quoted lists, I take your point. For the sequence operations examples it was somewhat deliberate, in that a sequence is a very different datatype from a vector but pretty much the same as a list. I had a bug in some code that conj'ed elements onto a vector, but for some reason it would switch direction in the middle and start adding elements at the opposite end. It took me a while to figure out that it was because concat'ing two vectors doesn't return a vector. So I wanted to emphasize that using a sequence op on anything other than a list is also a conversion from one datatype to another. But I'll take another look, there may be better ways. Thanks for your comments, much appreciated. I'll include them with the next update. Sincerely, jf -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
closure discrepancy
I noticed that (def z (let [d 3] (fn [] d))) (eval `(identity ~z)) fails and raises java.lang.ExceptionInInitializerError while (def y (fn [] 3)) (eval `(identity ~y)) works properly. Is there some rule about evaluating closures I'm missing here? Notes: Using latest 1.2.0-SNAPSHOT commit 04764db9b213687dd5d4325c67291f0b0ef3ff33 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Executable clojure scripts (#!/usr/bin/env clj)
On Tue, Jul 13, 2010 at 1:55 PM, Paul Richards wrote: > I'm new to Clojure, and I've found it possible to make Clojure scripts > executable by adding '#!/usr/bin/env clj' as the first line (and > 'chmod +x' of course). > > E.g. My sample script: > > #!/usr/bin/env clj > > (println "Hello World") > > This seems like a very convenient way to dabble with Clojure, yet I > have not seen it suggested anywhere. Is this method discouraged? Since there's no standard shell launcher for clj[1], you don't really have a good idea of how it will work, especially when you need to use more than one file. Once classpath issues come into play things become a lot more complicated. You would need something like Hashdot for that: http://hashdot.sourceforge.net/ -Phil [1] According to a ticket in assembla, this may be fixed post 1.2, which I'm glad to see. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Deview - Better test results
On Tue, Jul 13, 2010 at 12:33 PM, Brenton wrote: > Deview is a tool for running tests in Leiningen projects which use > clojure.test. Test results are much better than plain text. Any > exception, either at compile time or in a test failure, is filtered > using clj-stacktrace. For other failures a diff of the two forms is > displayed. > > I hope someone else finds this as useful as I do. This is really cool! Unfortunately since I spend all my time in the terminal, (for remote pairing) I can't really use a web-based interface like this for normal work. Do you have any plans to create a command-line client? How hard would it be? Alternatively, do you know how much work it would be to wire difform directly into clojure.test so you'd get readable results from a standard "lein test" run? -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure on BEAM
On Mon, 12 Jul 2010 02:06:05 -0700 (PDT) Krukow wrote: > > On Jul 11, 11:55 am, stewart wrote: > > Hi All, > > > > Has anybody considered implementing Clojure on BEAM. Are there any > > works or current attempts currently available? > > > > In your view where are the real trip ups for this to happen. I looked into targeting a language to BEAM, and honestly the biggest obstruction for me at that time was that BEAM's bytecodes were (are currently?) not documented really at all. Maybe efforts like LFE (Lisp Flavoured Erlang) and Reia will change that as other people become interested in targeting their languages at BEAM. Currently I *believe* Reia is implemented as a cross-compiler, emitting Erlang source and immediately compiling it with the compile module, which completely sidesteps that issue. Someone else (Robert Virding?) would have to speak for LFE's compiler. It probably emits beamfiles directly but since I believe Robert, you know, wrote large portions of the emulator, he probably does not require a bytecode reference. :) Other obstacles I can see: * Implementing Clojure's shared-memory primitives like refs, agents, atoms on BEAM which AFAIK fairly strictly enforces shared-nothing. If one is willing to write Clojure in a non-shared-memory, Erlang-like style, they may simply opt to discard them, or substitute some sort of Clojure-flavored actor primitives to embrace the message-passing style of Erlang. This would not bother me that much (see [1]), but many others would argue it's not Clojure anymore and that you might as well use LFE. Or, alternatively, one might investigate using ETS or Mnesia memory tables for "shared memory", the latter already having transactional semantics. The fact that Clojure explicitly demarcates shared state makes this, on it's face, seem imminently doable, although likely with lots of performance red flags. * Data structures. BEAM does not have a native map or vector, let alone persistent ones, and ones written in Erlang/Clojure are likely to be slow. On the plus side, the data structures you do get (list and tuple) are already immutable, so no "this thing from Java-land might be mutable" wierdness that can occasionally happen on the JVM/CLR. Still, this could be a deal-breaker, I think, unless someone smarter than I am sees a good way to fit the data types together (again, see [1]). All that said, Clojure-in-Clojure (when it arrives) would make such an effort a lot easier. I'd wait for that even if I already had my mind set on porting Clojure. > > Instead you should take a look at Erjang > > /karl > My personal opinion was always that the BEAM emulator and it's process model was the really compelling part of Erlang, less so the language itself, so a JVM implementation of the Erlang language never seemed that interesting to me. But I have to admit, the performance numbers Erjang is posting took me completely by surprise. A stroke of brilliance using Kilim for the scheduler; I think my previous indifference assumed a naive JVM Erlang implementation that mapped processes onto Java threads and, you know, sucked. That said, I still think BEAM is pretty dang cool, and I continue to quietly root for implementers trying to target other languages to it. -Kyle [1] Clojure's appeal, for me, comes 95% from the fact that it's a lisp that has sane data structures as *first class members of the language*. Everything else, including a lot of what people like to brag about in Clojure like STM and being on the JVM, is icing as far as I'm concerned. I tried to learn Common Lisp, but when I found out that something as simple as a vector or a hash map was a second-rate data structure, I lost interest and went back to Python. Data structure seamlessness is frankly worth more to me than macros, because I need a vector or a hash map 100x more often than I need a macro. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Deview - Better test results
Phil, Could you give me a little more detail as to why you can't use it? I also work from the command line and this works very well for me. I thought that this would work well for remote pairing. Do you work from sources on your machine or from a server? Either way you should be able to add the server to your project. The client can run from anywhere. You can run one centralized client or one for each team member. The main advantage of the web interface is that you have so many more options for displaying information. Having said that, if you cannot use it as it is or if you and others think that a command line version would be better, then I would be happy to do it. That would be much easier than what I have already done. Would you prefer a command line "client" so that you would still run the server from your project and you could have any number of clients connect to the same test server; or would it be better to just have a Leiningen plugin that runs tests and formats the results with difform and clj-stacktrace? Either would we fairly easy given the work I have already done. Brenton On Jul 13, 9:40 pm, Phil Hagelberg wrote: > On Tue, Jul 13, 2010 at 12:33 PM, Brenton wrote: > > Deview is a tool for running tests in Leiningen projects which use > > clojure.test. Test results are much better than plain text. Any > > exception, either at compile time or in a test failure, is filtered > > using clj-stacktrace. For other failures a diff of the two forms is > > displayed. > > > I hope someone else finds this as useful as I do. > > This is really cool! > > Unfortunately since I spend all my time in the terminal, (for remote > pairing) I can't really use a web-based interface like this for normal > work. Do you have any plans to create a command-line client? How hard > would it be? > > Alternatively, do you know how much work it would be to wire difform > directly into clojure.test so you'd get readable results from a > standard "lein test" run? > > -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure on BEAM
On Jul 14, 2010, at 7:24 AM, Kyle Schaffrick wrote: > But I have to admit, the performance numbers > Erjang is posting took me completely by surprise. A stroke of > brilliance using Kilim for the scheduler; I think my previous > indifference assumed a naive JVM Erlang implementation that mapped > processes onto Java threads and, you know, sucked. Maybe it would make sense to build a version of Clojure's concurrency support that integrates with Kilim? Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Deview - Better test results
On Jul 14, 2010, at 6:40 , Phil Hagelberg wrote: > This is really cool! > > Unfortunately since I spend all my time in the terminal, (for remote > pairing) I can't really use a web-based interface like this for normal > work. Do you have any plans to create a command-line client? How hard > would it be? > > Alternatively, do you know how much work it would be to wire difform > directly into clojure.test so you'd get readable results from a > standard "lein test" run? > Hi Phil, you could use SSH port forwarding, it works like a charm on both *nix and windows (with putty) so you can access a remote http server that runs 'in private' regards, Heinz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure-based scientific paper!
Hi all, My first paper with results based on a clojure-build agent-based model is in press! If you have academic access to the journal, you can peek at it here: http://dx.doi.org/10.1016/j.epidem.2010.05.003 , but otherwise it is also available on mendeley: http://www.mendeley.com/profiles/boris-schmid/ A very old and experimental version of the code is still in the files directory of the newsgroup (eden.clj), but I'll make some time to clean up the current version and drop it in the files directory as well. Several other papers using clojure are in the works as well, and by now I'm making heavy use of Incanter for visualization. Thanks for making these wonderful tools! The paper quoted above still uses xmgrace and inkscape. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
