Re: [clojure-rabbitmq] Re: Can TopologyRecoveryException be simulated?
On Jun 4, 2014, at 3:31 AM, Michael Klishin mklis...@gopivotal.com wrote: Feel free to contribute this feature: https://github.com/michaelklishin/langohr/issues/47 I'll have the new guy do it when he starts in August. Let us go then, TMI, When their profiles are spread out against the sky, Like a patient etherized upon a table. The Love Song of J. Random Profile -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Can TopologyRecoveryException be simulated?
On 4 June 2014 at 18:21:51, Brian Marick (br...@getset.com) wrote: I'll have the new guy do it when he starts in August. Hopefully it'll be done by then ;) -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
Once you notice that you usually need a fast solution. The easiest solution is to just pass around an instance of java.util.Random which you create with the desired seed. Another options is to have a constructor function returning a rand function. (defn prng [seed] (let [rnd (java.util.Random. (long seed))] (fn rand [] (.nextDouble rnd You can specify different arities as you need them. But obviously this is more limited than just passing around the Random object since you can't choose between the next* methods. But having a built-in rebindable (thread-local) rand is preferable in the long run. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
Hi Jeffrey, 'Jeffrey Cummings' via Clojure clojure@googlegroups.com writes: You may want to look at Docjure https://github.com/mjul/docjure It parses .xlsx files it may be able to parse .odt files. Thanks, but I don't see anything in docjure about parsing .odt files. Or am I missing something? -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
Hi Denis, Denis Fuenzalida denis.fuenzal...@gmail.com writes: I've created a small gist which shows how to use the ODFDOM API which is much simpler to use: https://gist.github.com/dfuenzalida/a1e9755e9b2e7f638620 Thanks a lot for this! I tested it and I can get the human readable text from an arbitrary .odt file. My next purpose is to get what getTextContent gives me, but with new lines preserved -- I used getContentDom so that I can get the full DOM and find new lines by replacing text:p../text:p ... but this feel dirty. Do you know if I can get paragraphs easily? Or should I manipulate the DOM with some other XML parsing tool? Thanks for your time, -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
Hi Pantomime right now doesn't support the text extraction, but you can take the https://github.com/alexott/clj-tika (outdate although) - it uses the Apache Tika for text extraction On Wed, Jun 4, 2014 at 1:27 AM, Bastien bastiengue...@gmail.com wrote: Hi all, I'm trying to get the content of an ODT file as plain text. I've found Pantomime, but don't understand how to use it? Can anyone put me on the right tracks with a minimal working example? Thanks in advance! -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Simbase: A vector similarity database
Hi，folks, Simbase v0.1.0-beta1 just release! We had fix many bugs，and the system are very stable for almost half a year in our cases。 In the docs, we add simple scenario for your references Setup bmk b2048 t1 t2 t3 ... t2047 t2048 vmk b2048 article vmk b2048 userprofile rmk userprofile article cosinesq Fill data vadd article 1 0.11 0.112 0.1123... vadd article 2 0.21 0.212 0.2123... ... vadd userprofile 1 0.11 0.112 0.1123... vadd userprofile 2 0.21 0.212 0.2123... ... Query rrec userprofile 2 article On Sun, Jan 26, 2014 at 9:21 AM, Mingli Yuan mingli.y...@gmail.com wrote: Hi, folks, This week we released v0.1.0-alpha3 * Remove constrains on vectors, Simbase support arbitrary vectors now * Fix various bugs on memory structure to keep scale ratio linearly * Almost 7 times improvement on performance, right now it can handle 100k dimensional dense vectors in under 0.14 sec on a i7-cup mac laptop. From now on, it enter the beta phase. If it is relevant to your work, we encourage you to have a try, and help us to find more bugs. Regards, Mingli On Mon, Jan 13, 2014 at 5:55 PM, Mingli Yuan mingli.y...@gmail.com wrote: Hi, folks, We just release an alpha version of Simbase, a vector similarity database that talks redis protocol. Since it is the first version of all its releases, we decided to keep it in alpha right now, for we want to hear from the community for any comments and improvements. Github page -- https://github.com/guokr/simbase We introduce the basic idea, limitations, build process and commands there. Background -- Simbase is a tool we developed during the process we revise our content recommendation engine. Our document set have 300k docs, and we use LDA to change them into vectors. But how to compare the 300k vectors was a problem for us then. We had tried different method, but the performance is not very good. Since the comparison logic is quit simple, we decided to write a new data store to do the tricks. So far, we are satisfied by its performance. Under the setting of an i7 MacBook and 120k 1k-dimensional vector set: - write: about 1 ops per second - read: up to 1k ops per second The real read performance may be higher than the current result, because our testing method is limited. Regards, Mingli -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Gary Trakhman gary.trakh...@gmail.com writes: Knowing with certainty that some called method is defined above in the compilation strategy simplifies code-reading and comprehension by minimizing where you have to look, and it also makes it easier to move stuff around with a text editor than what I imagine the alternative would provide. I never really care about backward or forward when jumping about code. The editors take care of it for me. I haven't used a late-binding lisp in a large code-base, so I'm contrasting against my experience with Java. It's a total pain in the ass. You write some lisp, start to debug it carefully, and half way through hit a mispelt symbol. (defun thing[fred x] (funcall frd x)) In Clojure, the closest equivalent (hitting a symbol you have declared, but not defined) is rare: (declare frd) (defun thing[fred x] (frd x)) Although, pre-declaration doesn't prevent a related bug which is using a symbol that you *think* is local but is actually global as in: (defn blah [mp] (do-stuff-to map)) Having said this this, having to declare things first and being forced to write bottom up is also a pain. Win some, lose some. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Gregg Reynolds d...@mobileink.com writes: This is not side-effect free (sorry for pun). I did this for my code, and now slamhound doesn't work on it. Other tools too? I don't know. https://github.com/technomancy/slamhound/issues/61 (load foo) is legal Clojure; if a tool can't handle it, that's either a bug or a deliberate limitation in the tool. If you read the bug report, you will see that I agree. The slamhound developers don't and argue that (load foo) is bad style. Who is right is not so relevant; that there is such an argument is. So I wouldn't say that using load has side-effects that break tools, but that some tools may make assumptions and have side-effects that do nasty things to legal code (or encourage a particular style). I would not be surprised if other tools make similar assumptions about the structure of clojure source files. Then it's a question of whether one wants to allow the limitations of tools to constrain one's use of the language. Or whether one's use of the language limits the ability to use tools. I just make the statement that it good to know about these choices rather than to make them by chance. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Are zippers the right choice for sequence-like trees?
I am working with “sequence like” trees - by which I mean that they’re very broad (typically the root node will have several thousand children) and shallow (no more than 2 levels deep). I’m often dealing with a degenerate tree that’s really just a sequence (all the nodes in the tree are children of the root). A typical edit is either changing the value of a single element, inserting a single element, or deleting a small set of contiguous elements. I’m currently using clojure.zip to edit the tree, and it’s working just fine. But I’m concerned that it won’t be giving me much value in terms of structure sharing for this type of tree and this type of edit. So I have two questions: 1) What would be a good way for me to instrument my code to determine what level of structure sharing I am achieving? 2) Should I consider switching to something based on (say?) rrb-vector? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel http://pragprog.com/book/pb7con -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
Hi Alex, Alex Ott alex...@gmail.com writes: Pantomime right now doesn't support the text extraction, but you can take the https://github.com/alexott/clj-tika (outdate although) - it uses the Apache Tika for text extraction thanks -- I stumbled upon clj-tika but didn't understand how to use it. Would you have a minima example? The README is pretty terse. Thanks in advance, -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure Pretty Printing with Blogger
Hi i am trying to pretty a clojure code :
my emacs version is 24.3.1
my org file is :
#+BEGIN_SRC clojure
(defn foo [x]
(reverse (let [A (reduce
(fn [x y]
(if (= (:L x) y)
(assoc x :T (conj (:T x) y))
(assoc (assoc
(if (:L x)
(assoc x :V
(conj (:V x) (cons (:L x) (:T x)))
)
x)
:T nil)
:L y )
))
{} x)]
(conj (:V A) (cons (:L A) (:T A)))
)))
#+END_SRC
when i do C-c C-e h o, it open a file which shows code in a block but it is
not pretty.
On Friday, 25 May 2012 15:37:24 UTC+5:30, Jake Johnson wrote:
Hi, guys. Has anyone had any luck with using google-code-prettify
http://code.google.com/p/google-code-prettify/ and
http://google-code-prettify.googlecode.com/svn/trunk/src/lang-clj.js
together on blogger? I followed
http://www.tkglaser.net/2012/03/syntax-highlighting-in-blogger.html
http://www.tkglaser.net/2012/03/syntax-highlighting-in-blogger.html%20
, but I can't get Clojure to display correctly, at least yet.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Your chance to employ an experienced clojure team!
Hey Florian - I'm a developer over at CircleCI and we're definitely interested in seeing if there might be a fit here. Would someone one your team mind shooting me an e-mail at j...@circleci.com? I read everything that goes into that address so I can promise you won't be lost in any bureaucracy :) Cheers! - Dave On Tuesday, June 3, 2014 4:22:17 AM UTC-7, Florian Over wrote: Hey, you know how hard it is to find good clojure developers? This is your chance to hire a battle-proven team. :) Our startup shutdown the core product right and our whole clojure team is available from July. We would love to work together in this team in the future. Relocation is not really an option but contact us either way! (We are based in Cologne area, Germany) We developed a cloud-based document management solution for end-users and small/medium businesses. (Event-driven, CQRS architecture) We did the whole enchilada from architecture, concept, research development to hosting and operations. Some of the technologies we used: * ring, compojure, clojure-script, http-kit * prismatic-schema * ... dozen of other clojure libraries :) * pallet * riemann * zookeeper * postgres * AWS (ec2, s3, dynamoDB, SQS, Cloudfront, EMR, Cloudwatch, ...) Right now we are not allowed to show or open-source the code we developed. :( * Islon Scherer - https://github.com/stackoverflow * Emil Yessenamanov - https://github.com/mobyte * Gerrit Hentschel - https://github.com/gerrit-hntschl * Florian Over - https://github.com/FlorianO Feel free to contact me directly for more information. Best regards Florian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
store a value in a PersistentVector and PersistentHashMap
Hi all, do you know how is store a 'value' in a PersistentVector or in a PersistentHashMap ? Thanks Sorin. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
lein try clj-tika 1.2.0 user= (use 'tika) user= (def res (parse https://www.oasis-open.org/committees/download.php/25054/07-08-22-MetaData-Examples.odt )) #'user/res res - the map consisting of: - :text - extracted text - all other fields - metadata from document On Wed, Jun 4, 2014 at 2:33 PM, Bastien bastiengue...@gmail.com wrote: Hi Alex, Alex Ott alex...@gmail.com writes: Pantomime right now doesn't support the text extraction, but you can take the https://github.com/alexott/clj-tika (outdate although) - it uses the Apache Tika for text extraction thanks -- I stumbled upon clj-tika but didn't understand how to use it. Would you have a minima example? The README is pretty terse. Thanks in advance, -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Clojure on iOS devices - Swift as a host?
The recent release of Swift made me revisit Clojure on LLVM. This post from 2010 https://groups.google.com/d/msg/clojure/KrwtTsdYZ8I/Qf8PSMeoZCUJ suggests it's a very difficult task. Swift would make this job easier? As with ClojureScript, generate Swift code / provide interop and Clojurian's can produce native iOS apps? Perhaps the biggest hole to be filled would be tooling (Xcode is not Clojure/Lisp friendly? i.e. no playground support) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing ODT files (with Pantomime?)
Hi Alex, Alex Ott alex...@gmail.com writes: res - the map consisting of: - :text - extracted text - all other fields - metadata from document Works like a charm, thanks a bunch! -- Bastien -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Are zippers the right choice for sequence-like trees?
In general, I've found that zippers make complicated edits super-easy, while a recursive phrasing of the same algorithm - if it exists and isn't super complicated to write - performs better and gives more control over structural sharing. I might prove out an algorithm with zippers, but when the pedal hits the road for performance, I'll try to rephrase it. If you can phrase things in terms of (catvec (subvec ...) (subvec ...)), then I'll bet (but you should check) that rrb-vector will perform better and do more structural sharing. On Wed, Jun 4, 2014 at 8:29 AM, Paul Butcher p...@paulbutcher.com wrote: I am working with “sequence like” trees - by which I mean that they’re very broad (typically the root node will have several thousand children) and shallow (no more than 2 levels deep). I’m often dealing with a degenerate tree that’s really just a sequence (all the nodes in the tree are children of the root). A typical edit is either changing the value of a single element, inserting a single element, or deleting a small set of contiguous elements. I’m currently using clojure.zip to edit the tree, and it’s working just fine. But I’m concerned that it won’t be giving me much value in terms of structure sharing for this type of tree and this type of edit. So I have two questions: 1) What would be a good way for me to instrument my code to determine what level of structure sharing I am achieving? 2) Should I consider switching to something based on (say?) rrb-vector? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel http://pragprog.com/book/pb7con -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: store a value in a PersistentVector and PersistentHashMap
On Wednesday, June 4, 2014 4:32:00 PM UTC+3, François Rey wrote: On 04/06/14 14:59, sorin cristea wrote: do you know how is store a 'value' in a PersistentVector or in a PersistentHashMap ? Hi Sorin, Your question is difficult to understand without more context. Are you trying to use Clojure data structures from Java? http://www.lispcast.com/3-things-java-can-steal-from-clojure Are you trying to understand how to use clojure data structures? http://pleac.sourceforge.net/pleac_clojure/arrays.html http://pleac.sourceforge.net/pleac_clojure/hashes.html Are you trying to understand how clojure data structure work internally? http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-pt-2 http://hypirion.com/musings/understanding-persistent-vector-pt-3 Hi Francois, I'm trying to understand how clojure persistence data structure, specially PersistentVector and PersistentHashMap, work internally Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure on iOS devices - Swift as a host?
I'm starting to feel like a broken record, but here we go. Some things to think about: 1) Why do you want this? The JVM GC and JIT are some of the fastest (if not the fastest) on the planet, so performance will never be a good reason to do this. 2) Do you want something like eval? As far as I can tell Swift is statically compiled. Only XCode has the ability to modify a program on the fly. 3) Clojure is highly polymorphic and dynamically typed. Walk the source code for first and next and you'll find something like 3-4 polymorphic calls involved in something as simple as (doseq [x (range 100)]), per item. 4) I have yet to see performance numbers for Swifthow fast/slow is it compared to other languages? To put this all into perspective, I once translated LazySeq to C++ and ran some code (with a GC) that performed something like (doall (range 10)). The result was about 10x slower than Clojure on the JVM. So simply running something in C++/LLVM doesn't mean that you'll even get close to the performance of the JVM. Memory constrained systems might benefit from a LLVM Clojure. In addition there's room for improvement with the JVM's horrible warmup times. Python will boot instantly on most systems while the Clojure REPL takes about a minute to boot on the RPi. But aside form that, I can't see much of a point. If you want something like this there's always ( https://github.com/galdolber/clojure-objc) Timothy On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp virtual.g...@gmail.com wrote: The recent release of Swift made me revisit Clojure on LLVM. This post from 2010 https://groups.google.com/d/msg/clojure/KrwtTsdYZ8I/Qf8PSMeoZCUJ suggests it's a very difficult task. Swift would make this job easier? As with ClojureScript, generate Swift code / provide interop and Clojurian's can produce native iOS apps? Perhaps the biggest hole to be filled would be tooling (Xcode is not Clojure/Lisp friendly? i.e. no playground support) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: store a value in a PersistentVector and PersistentHashMap
If you've read those sites, then read the source. It's not that hard to understand once you understand that Vectors are trees: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentVector.java On Wed, Jun 4, 2014 at 7:46 AM, sorin cristea srncris...@gmail.com wrote: On Wednesday, June 4, 2014 4:32:00 PM UTC+3, François Rey wrote: On 04/06/14 14:59, sorin cristea wrote: do you know how is store a 'value' in a PersistentVector or in a PersistentHashMap ? Hi Sorin, Your question is difficult to understand without more context. Are you trying to use Clojure data structures from Java? http://www.lispcast.com/3-things-java-can-steal-from-clojure Are you trying to understand how to use clojure data structures? http://pleac.sourceforge.net/pleac_clojure/arrays.html http://pleac.sourceforge.net/pleac_clojure/hashes.html Are you trying to understand how clojure data structure work internally? http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-pt-2 http://hypirion.com/musings/understanding-persistent-vector-pt-3 Hi Francois, I'm trying to understand how clojure persistence data structure, specially PersistentVector and PersistentHashMap, work internally Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
On Sunday, June 1, 2014 9:36:55 AM UTC-5, Glen Mailer wrote: Hi everyone, I'm looking to get some opinions on code style. Specifically, I like to write my code in a top-down. What I mean by that is that within a file the highest-level functions sit at the top, and are implemented in terms of lower-level functions further down. ... There's a few approaches i've seen from reading other's code: ... Some other options I considered include making really heavy use of (declare), ... I'm puzzled by the complexity of the solutions proposed. (Although I like Luc's, since my computer doesn't have an auto-rotate function.) I don't see this as a big deal at all. I just put a big declare statement at the top of the file. More specifically, when initially coding related functions, I'll put the dependent ones below the ones they call. After that chunk of code is done, I might move the higher-level functions up in the file. Then I add the new functions to the declare statement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declare statement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declare in one pass. That works for defn and defn-, and you might want to shorten the search term to 'def'. It's more difficult if you use Clojure protocols. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Clojure on iOS devices - Swift as a host?
I have been experimenting writing an iOS app using ClojureScript embedded in JavaScriptCore, where the ClojureScript essentially implements the logic of my view controllers which drive native UI. So far, this approach seems like a reasonable one to “writing iOS apps using Clojure.” You essentially trade off direct tooling support and gain the ease of developing using ClojureScript (this is important to me, as my server is in Clojure and I can effectively master one language.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure on iOS devices - Swift as a host?
@Timothy, you mention speed a lot, but I'm not sure where in the OP it mentioned wanting to do this for speed at all. I think the intention is to be able to Clojure on a different platform, is all. On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes mikefi...@me.com wrote: I have been experimenting writing an iOS app using ClojureScript embedded in JavaScriptCore, where the ClojureScript essentially implements the logic of my view controllers which drive native UI. So far, this approach seems like a reasonable one to “writing iOS apps using Clojure.” You essentially trade off direct tooling support and gain the ease of developing using ClojureScript (this is important to me, as my server is in Clojure and I can effectively master one language.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declare statement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declare statement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declare in one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
trouble using local jars in project
I'm having trouble using local jars in my project. I've built the jars and installed them with localrepo. wei:clj-opencv wei$ lein localrepo install opencv-249.jar opencv/opencv 2.4.9 wei:clj-opencv wei$ lein localrepo install opencv-native-249.jar opencv/opencv-native 2.4.9 The jars show up in the local repo list. wei:pv wei$ lein localrepo list | grep opencv opencv/opencv-native (2.4.9) opencv (2.4.9) I then included opencv in my project.clj with [opencv/opencv 2.4.9]. But leiningen can't find the jar when I run the project: wei:pv wei$ lein run Could not find artifact opencv:opencv:jar:2.4.9 in central (http://repo1.maven.org/maven2/) Could not find artifact opencv:opencv:jar:2.4.9 in clojars (https://clojars.org/repo/) Could not find artifact opencv:opencv:jar:2.4.9 in project (file:repo) This could be due to a typo in :dependencies or network issues. If you are behind a proxy, try setting the 'http_proxy' environment variable. I wonder if the problem is specific to opencv since I've used localrepo successfully for other jars. Any pointers would be appreciated. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Clearly the solution is to use tools.analyzer and write a big def emitter /s Reid On 06/04/2014 10:27 AM, Mars0i wrote: On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declarestatement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declarestatement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declarein one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] clj-generators - generator magic inspired by Python
What new features does this syntax provide over the existing infinite sequence generators? - lazy-seq - iterate - repeat - repeatedly - range I realize you provided a simple example for clarity, but perhaps you could illustrate something more complex that couldn't be done with the above functions easily. For example, the case you provided could be written as follows: (take 5 (iterate inc 1)) Thanks, ~Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
I actually have an open issue for Cursive to do this automatically: #200 https://github.com/cursiveclojure/cursive/issues/200. I'm starting to think a namespace sorter that automatically manages the declares might not be such a crazy idea. On 5 June 2014 03:37, Reid McKenzie rmckenzi...@gmail.com wrote: Clearly the solution is to use tools.analyzer and write a big def emitter /s Reid On 06/04/2014 10:27 AM, Mars0i wrote: On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declare statement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declare statement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declare in one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] clj-generators - generator magic inspired by Python
A little known fact is that the guts of the go macro are quite flexible. We use this in the test framework: https://github.com/clojure/core.async/blob/master/src/test/clojure/clojure/core/async/ioc_macros_test.clj#L17 I also spent some time once and created a yield like macro: https://github.com/halgari/async-bench/blob/master/src/async_bench/core.clj#L64 WARNING: this uses unpublished APIs from core.async, use at your own risk. Timothy On Wed, Jun 4, 2014 at 9:43 AM, Gary Johnson gwjoh...@uvm.edu wrote: What new features does this syntax provide over the existing infinite sequence generators? - lazy-seq - iterate - repeat - repeatedly - range I realize you provided a simple example for clarity, but perhaps you could illustrate something more complex that couldn't be done with the above functions easily. For example, the case you provided could be written as follows: (take 5 (iterate inc 1)) Thanks, ~Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Then integrate the whole lot into the Clojure compiler pipeline so that it just works in the first place. Reid McKenzie rmckenzi...@gmail.com writes: Clearly the solution is to use tools.analyzer and write a big def emitter /s Reid On 06/04/2014 10:27 AM, Mars0i wrote: On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declarestatement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declarestatement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declarein one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
I maintain that the average human being looking at sed commands would rather end up standing on his head for a significant amount of time to avoid it :))) BTWY, I have been scripting under u*x for a few decades by now. I resort to it when nothing and I mean nothing (think about Daffy Duck's voice here) else can do it :)) Luc P. Luc P. On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declare statement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declare statement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declare in one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Hi everyone, I'm looking to get some opinions on code style. Specifically, I like to write my code in a top-down. What I mean by that is that within a file the highest-level functions sit at the top, and are implemented in terms of lower-level functions further down. You could write a (defn-defer ... macro that asserts the signature and caches the code body. The final function in your file would be (do-defer ...) which does the actual (defn ... forms. Tim Daly -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
On Jun 2, 2014, at 7:14 PM, Gary Johnson gwjoh...@uvm.edu wrote: Hey Lee, I would second Jozef's suggestion that you look into using the reducers library when you need non-lazy sequence operations. [etc] On Jun 2, 2014, at 10:38 PM, Lee Spector lspec...@hampshire.edu wrote: Gary: That's compelling indeed, and I will look into it more! Some quick notes and a question from my first look into this: - I watched a Rich Hickey reducers video, was riveted, and see that they are beautiful. I particularly appreciated his brief aside about how lazy seqs have independent utility. - In practice, for the little program I posted about previously, switching to reducers involved a couple of initially unexpected complications, some of now make sense to me but others of which don't fully: results of reducers sometimes have to be explicitly converted, e.g. with into []; r/map doesn't take multiple collections; I don't immediately see elegant reducer-based approaches to uses of for or repeat, etc. - My initial swapping of clojure.core.reducers functions for lazy seq (and agent-based parallel computing) functions seems to make my performance worse rather than better. I realize that there are several possible explanations for this and I have to look at my usage more carefully. It's definitely possible that I'm doing more than one thing wrong, but one question that this leads to is: - If I operate on a vector with a sequence of r/map and r/filter operations and finally with into [] to get back a vector, then I think that fold will be called within the call to into, and that parallelism should happen there... right? But if that's right, how do I control the group size that the call to fold uses in this case? I see how to specify the group size for a direct call to fold, but not for other function in the library. Thanks, -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
Hey Lee,
(vec ...) is NOT the same as (into [] ...) in this case.
Whenever you use a reducing function, like r/map, r/filter, r/mapcat, and
so on, you are not, in fact, performing any computations on the collection
to which you apply it. These functions simply wrap the collection with a
kind of delayed operation that will later be triggered by applying reduce
to it.
So, if I have a collection called samples, and I run (r/map inc samples),
I just get a reducible object back. Same thing with a chain of these
functions as in (r/filter odd? (r/map inc samples)). I just get back a
reducible object (which itself is wrapping another reducible object). When
you run reduce on this whole thing, each of the delayed operations are
combined together into one giant reduce function, as if you had written
something like this:
(reduce + (r/filter odd? (r/map inc samples)))
= (reduce (fn [sum sample] (let [sample' (inc sample)] (if (odd?
sample') (+ sample' sum) sum))) 0 samples)
This is the reason that you need to use (into [] ...) rather than (vec
...). Running vec on a reducible object will just throw a RuntimeException.
When you use into, you will be applying reduce (since that's how it is
implemented), and as long as you use into with a vector, map, or set, it
will be run using transients for efficiency.
Uses transients:
(into [] (r/map inc (range 10)))
(into {} (r/map #(vector % 0) (range 10)))
(into #{}| (r/map inc (range 10)))
Doesn't use transients (but still works). Note that the list will have
been reversed because of the nature of list consing:
(into () (r/map inc (range 10)))
Alright, hopefully that's enough from me for now. Good luck with your
program.
~Gary
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Clojure on iOS devices - Swift as a host?
I wasn't really pointing at performance with my post. More about native app development, for OSX we have Clojure on the JVM which is fine. I don't see Apple allowing Java on iOS anytime though. Thanks for the replies so far, this was purely food for thought. On Wednesday, 4 June 2014 16:11:56 UTC+1, Aaron France wrote: @Timothy, you mention speed a lot, but I'm not sure where in the OP it mentioned wanting to do this for speed at all. I think the intention is to be able to Clojure on a different platform, is all. On Wed, Jun 4, 2014 at 4:58 PM, Mike Fikes mike...@me.com javascript: wrote: I have been experimenting writing an iOS app using ClojureScript embedded in JavaScriptCore, where the ClojureScript essentially implements the logic of my view controllers which drive native UI. So far, this approach seems like a reasonable one to “writing iOS apps using Clojure.” You essentially trade off direct tooling support and gain the ease of developing using ClojureScript (this is important to me, as my server is in Clojure and I can effectively master one language.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
On Jun 4, 2014, at 12:59 PM, Gary Johnson gwjoh...@uvm.edu wrote: Hey Lee, (vec ...) is NOT the same as (into [] ...) in this case. [etc] Thanks Gary -- very clear and helpful. -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
Hey Lee, answers below. Also make sure to read my other post at 12:59pm today regarding the behavior of vec vs. into for reducible collections. On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote: Some quick notes and a question from my first look into this: - I watched a Rich Hickey reducers video, was riveted, and see that they are beautiful. I particularly appreciated his brief aside about how lazy seqs have independent utility. - In practice, for the little program I posted about previously, switching to reducers involved a couple of initially unexpected complications, some of now make sense to me but others of which don't fully: results of reducers sometimes have to be explicitly converted, e.g. with into []; r/map doesn't take multiple collections; I don't immediately see elegant reducer-based approaches to uses of for or repeat, etc. It's true that the library does have these limitations. You could, of course, just implement a for-like macro that uses the reducing operations under the hood. Easier (but less readable) is to just convert your for into the equivalent r/map and r/filter operations. When using repeat, make sure the result sequence will be finite and call vec on it directly. Then you can apply the reducing functions to it and still have a foldable collection. - My initial swapping of clojure.core.reducers functions for lazy seq (and agent-based parallel computing) functions seems to make my performance worse rather than better. I realize that there are several possible explanations for this and I have to look at my usage more carefully. It's definitely possible that I'm doing more than one thing wrong, but one question that this leads to is: Hard to say why this would be without seeing your code, but the first thing that comes to mind is that if you aren't calling fold or foldcat anywhere, then you won't be getting any parallelization from using reducers. So maybe your performance decrease is because you're now running single-threaded. - If I operate on a vector with a sequence of r/map and r/filter operations and finally with into [] to get back a vector, then I think that fold will be called within the call to into, and that parallelism should happen there... right? But if that's right, how do I control the group size that the call to fold uses in this case? I see how to specify the group size for a direct call to fold, but not for other function in the library. No, fold will not be called in into. The definition of into uses reduce, which is single-threaded. What you want is one of the following two formulations: (fold group-size cat append! foldable-collection) ;; if you want to specify the group size (foldcat foldable-collection) ;; if you are happy with the default 512 group size In both cases, the foldable-collection is just one of your (r/map f (r/filter p? initial-collection)) forms. For it to be foldable though, initial-collection needs to be a vector, map, or set (i.e., a tree-like collection). I hope that helps. ~Gary Thanks, -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
Although your original complaint was about clojure seqs being lazy. It should be noted that reducers are also lazy down to the point of a fold or reduce, so I'm not sure what you're really getting there. It wouldn't be hard at all to write map, filter, remove, etc. in terms of list operations. Perhaps that's what you're looking for? If I understand your original complaint, you want map, filter, etc, to be eager. On the other hand, time spent learning how lazy seqs work, and the caveats involved will make it easier for you to understand the code produced by the rest of the community. So perhaps that's the better option. Timothy On Wed, Jun 4, 2014 at 11:20 AM, Gary Johnson gwjoh...@uvm.edu wrote: Hey Lee, answers below. Also make sure to read my other post at 12:59pm today regarding the behavior of vec vs. into for reducible collections. On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote: Some quick notes and a question from my first look into this: - I watched a Rich Hickey reducers video, was riveted, and see that they are beautiful. I particularly appreciated his brief aside about how lazy seqs have independent utility. - In practice, for the little program I posted about previously, switching to reducers involved a couple of initially unexpected complications, some of now make sense to me but others of which don't fully: results of reducers sometimes have to be explicitly converted, e.g. with into []; r/map doesn't take multiple collections; I don't immediately see elegant reducer-based approaches to uses of for or repeat, etc. It's true that the library does have these limitations. You could, of course, just implement a for-like macro that uses the reducing operations under the hood. Easier (but less readable) is to just convert your for into the equivalent r/map and r/filter operations. When using repeat, make sure the result sequence will be finite and call vec on it directly. Then you can apply the reducing functions to it and still have a foldable collection. - My initial swapping of clojure.core.reducers functions for lazy seq (and agent-based parallel computing) functions seems to make my performance worse rather than better. I realize that there are several possible explanations for this and I have to look at my usage more carefully. It's definitely possible that I'm doing more than one thing wrong, but one question that this leads to is: Hard to say why this would be without seeing your code, but the first thing that comes to mind is that if you aren't calling fold or foldcat anywhere, then you won't be getting any parallelization from using reducers. So maybe your performance decrease is because you're now running single-threaded. - If I operate on a vector with a sequence of r/map and r/filter operations and finally with into [] to get back a vector, then I think that fold will be called within the call to into, and that parallelism should happen there... right? But if that's right, how do I control the group size that the call to fold uses in this case? I see how to specify the group size for a direct call to fold, but not for other function in the library. No, fold will not be called in into. The definition of into uses reduce, which is single-threaded. What you want is one of the following two formulations: (fold group-size cat append! foldable-collection) ;; if you want to specify the group size (foldcat foldable-collection) ;; if you are happy with the default 512 group size In both cases, the foldable-collection is just one of your (r/map f (r/filter p? initial-collection)) forms. For it to be foldable though, initial-collection needs to be a vector, map, or set (i.e., a tree-like collection). I hope that helps. ~Gary Thanks, -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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
Re: Clojure on iOS devices - Swift as a host?
I wouldn't pass judgement on Swift too soon. Eval works just fine in the REPL and it appears the language supports hot code loads out of the box. Swift also has real support for final fields via 'let'. I personally think a ClojureSwift could be quite interesting :) On Wednesday, June 4, 2014, Timothy Baldridge tbaldri...@gmail.com wrote: I'm starting to feel like a broken record, but here we go. Some things to think about: 1) Why do you want this? The JVM GC and JIT are some of the fastest (if not the fastest) on the planet, so performance will never be a good reason to do this. 2) Do you want something like eval? As far as I can tell Swift is statically compiled. Only XCode has the ability to modify a program on the fly. 3) Clojure is highly polymorphic and dynamically typed. Walk the source code for first and next and you'll find something like 3-4 polymorphic calls involved in something as simple as (doseq [x (range 100)]), per item. 4) I have yet to see performance numbers for Swifthow fast/slow is it compared to other languages? To put this all into perspective, I once translated LazySeq to C++ and ran some code (with a GC) that performed something like (doall (range 10)). The result was about 10x slower than Clojure on the JVM. So simply running something in C++/LLVM doesn't mean that you'll even get close to the performance of the JVM. Memory constrained systems might benefit from a LLVM Clojure. In addition there's room for improvement with the JVM's horrible warmup times. Python will boot instantly on most systems while the Clojure REPL takes about a minute to boot on the RPi. But aside form that, I can't see much of a point. If you want something like this there's always ( https://github.com/galdolber/clojure-objc) Timothy On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp virtual.g...@gmail.com javascript:_e(%7B%7D,'cvml','virtual.g...@gmail.com'); wrote: The recent release of Swift made me revisit Clojure on LLVM. This post from 2010 https://groups.google.com/d/msg/clojure/KrwtTsdYZ8I/Qf8PSMeoZCUJ suggests it's a very difficult task. Swift would make this job easier? As with ClojureScript, generate Swift code / provide interop and Clojurian's can produce native iOS apps? Perhaps the biggest hole to be filled would be tooling (Xcode is not Clojure/Lisp friendly? i.e. no playground support) -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com'); For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com'); For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: Clojure on iOS devices - Swift as a host?
Does Swift have any static types to harvest? :) On Thu, Jun 5, 2014 at 1:50 AM, David Nolen dnolen.li...@gmail.com wrote: I wouldn't pass judgement on Swift too soon. Eval works just fine in the REPL and it appears the language supports hot code loads out of the box. Swift also has real support for final fields via 'let'. I personally think a ClojureSwift could be quite interesting :) On Wednesday, June 4, 2014, Timothy Baldridge tbaldri...@gmail.com wrote: I'm starting to feel like a broken record, but here we go. Some things to think about: 1) Why do you want this? The JVM GC and JIT are some of the fastest (if not the fastest) on the planet, so performance will never be a good reason to do this. 2) Do you want something like eval? As far as I can tell Swift is statically compiled. Only XCode has the ability to modify a program on the fly. 3) Clojure is highly polymorphic and dynamically typed. Walk the source code for first and next and you'll find something like 3-4 polymorphic calls involved in something as simple as (doseq [x (range 100)]), per item. 4) I have yet to see performance numbers for Swifthow fast/slow is it compared to other languages? To put this all into perspective, I once translated LazySeq to C++ and ran some code (with a GC) that performed something like (doall (range 10)). The result was about 10x slower than Clojure on the JVM. So simply running something in C++/LLVM doesn't mean that you'll even get close to the performance of the JVM. Memory constrained systems might benefit from a LLVM Clojure. In addition there's room for improvement with the JVM's horrible warmup times. Python will boot instantly on most systems while the Clojure REPL takes about a minute to boot on the RPi. But aside form that, I can't see much of a point. If you want something like this there's always ( https://github.com/galdolber/clojure-objc) Timothy On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp virtual.g...@gmail.com wrote: The recent release of Swift made me revisit Clojure on LLVM. This post from 2010 https://groups.google.com/d/msg/clojure/KrwtTsdYZ8I/Qf8PSMeoZCUJ suggests it's a very difficult task. Swift would make this job easier? As with ClojureScript, generate Swift code / provide interop and Clojurian's can produce native iOS apps? Perhaps the biggest hole to be filled would be tooling (Xcode is not Clojure/Lisp friendly? i.e. no playground support) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To
Re: gemacl: Scientific computing application written in Clojure
On Tuesday, June 3, 2014 12:46:55 PM UTC-5, Mars0i wrote: (def ones (doall (repeat 1000 1))) (bench (def _ (doall (map rand ones ; 189 microseconds average time (bench (def _ (doall (pmap rand ones ; 948 microseconds average time For the record, I worried later that rand was too inexpensive, and that those results were being driven only by the cost of setting up threads in pmap. This seems like a better test: (bench (def _ (doall (map #(nth (iterate rand %) 1) (repeat 256 1) ; 185 milliseconds average time (bench (def _ (doall (pmap #(nth (iterate rand %) 1) (repeat 256 1) ; 793 milliseconds average time I have been having success getting a speedup simply by changing certain map calls to pmap in my main project. I'm sure that many of us will be interested in a report whenever you get to it, but I can easily imagine that finding the time to summarize what you've learned is difficult. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
On Tuesday, June 3, 2014 4:56:26 PM UTC-5, Andy Fingerhut wrote: This ticket seems to be at least somewhat related to your questions: http://dev.clojure.org/jira/browse/CLJ-1420 Andy Yes, thanks for finding that, Andy. It looks like it would address the problem about accessing an RNG from distinct threads, and the discussion raises the issue of ability to reset the seed in order to replay experiments. (Incidentally, I realized that comparing (map rand ...) and (pmap rand ...) might be a poor test, because rand might be too inexpensive to overcome the cost of thread setup by pmap. I reported a better test in a post here https://groups.google.com/d/msg/clojure/L8ZNHReaKzM/Fyi4RC6ASEkJ.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote: Once you notice that you usually need a fast solution. Yes! The easiest solution is to just pass around an instance of java.util.Random which you create with the desired seed. Another options is to have a constructor function returning a rand function. (defn prng [seed] (let [rnd (java.util.Random. (long seed))] (fn rand [] (.nextDouble rnd Thanks. This is very helpful. I have not been thoroughly immersed in the Java world for many years, so I have to spend a bit of time studying in order to figure out this sort of thing on my own. (I like Clojure because I usually only need to deal with Java when I want to, but there are times when it's necessary.) But having a built-in rebindable (thread-local) rand is preferable in the long run. Yes, especially since rolling one's own version means coding up any higher-level functions that use randomness, when others who have thought more about relevant algorithms have already done that work. Then again, their source code is usually available, so one can copy it. For my present purposes, data.generators or bigml/sampling might do what I need. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
Data.generative already has this function and many more, I realized. /Linus On Wednesday, June 4, 2014, Mars0i marsh...@logical.net wrote: On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote: Once you notice that you usually need a fast solution. Yes! The easiest solution is to just pass around an instance of java.util.Random which you create with the desired seed. Another options is to have a constructor function returning a rand function. (defn prng [seed] (let [rnd (java.util.Random. (long seed))] (fn rand [] (.nextDouble rnd Thanks. This is very helpful. I have not been thoroughly immersed in the Java world for many years, so I have to spend a bit of time studying in order to figure out this sort of thing on my own. (I like Clojure because I usually only need to deal with Java when I want to, but there are times when it's necessary.) But having a built-in rebindable (thread-local) rand is preferable in the long run. Yes, especially since rolling one's own version means coding up any higher-level functions that use randomness, when others who have thought more about relevant algorithms have already done that work. Then again, their source code is usually available, so one can copy it. For my present purposes, data.generators or bigml/sampling might do what I need. -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com'); For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
Sorry, of course i meant the clojure.data.generators library https://github.com/clojure/data.generators esp. the *rnd* that can be bound around many of the functions in the library. /Linus On Wednesday, June 4, 2014, Linus Ericsson oscarlinuserics...@gmail.com wrote: Data.generative already has this function and many more, I realized. /Linus On Wednesday, June 4, 2014, Mars0i marsh...@logical.net javascript:_e(%7B%7D,'cvml','marsh...@logical.net'); wrote: On Wednesday, June 4, 2014 2:55:20 AM UTC-5, Gunnar Völkel wrote: Once you notice that you usually need a fast solution. Yes! The easiest solution is to just pass around an instance of java.util.Random which you create with the desired seed. Another options is to have a constructor function returning a rand function. (defn prng [seed] (let [rnd (java.util.Random. (long seed))] (fn rand [] (.nextDouble rnd Thanks. This is very helpful. I have not been thoroughly immersed in the Java world for many years, so I have to spend a bit of time studying in order to figure out this sort of thing on my own. (I like Clojure because I usually only need to deal with Java when I want to, but there are times when it's necessary.) But having a built-in rebindable (thread-local) rand is preferable in the long run. Yes, especially since rolling one's own version means coding up any higher-level functions that use randomness, when others who have thought more about relevant algorithms have already done that work. Then again, their source code is usually available, so one can copy it. For my present purposes, data.generators or bigml/sampling might do what I need. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
On Jun 4, 2014, at 1:20 PM, Gary Johnson gwjoh...@uvm.edu wrote: - If I operate on a vector with a sequence of r/map and r/filter operations and finally with into [] to get back a vector, then I think that fold will be called within the call to into, and that parallelism should happen there... right? But if that's right, how do I control the group size that the call to fold uses in this case? I see how to specify the group size for a direct call to fold, but not for other function in the library. No, fold will not be called in into. The definition of into uses reduce, which is single-threaded. What you want is one of the following two formulations: (fold group-size cat append! foldable-collection) ;; if you want to specify the group size (foldcat foldable-collection) ;; if you are happy with the default 512 group size In both cases, the foldable-collection is just one of your (r/map f (r/filter p? initial-collection)) forms. For it to be foldable though, initial-collection needs to be a vector, map, or set (i.e., a tree-like collection). I hope that helps. Definitely helpful. With the fold version, and messing with the group size, I'm seeing much higher multicore utilization and I think I'm seeing speedups too (although it's a little hard to measure because of randomness). I'm also having new problems (pauses that get worse over time... GC?) but I'll experiment more before I bother anyone else with those. Thanks so much Gary, -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
On Jun 4, 2014, at 1:29 PM, Timothy Baldridge tbaldri...@gmail.com wrote: Although your original complaint was about clojure seqs being lazy. It should be noted that reducers are also lazy down to the point of a fold or reduce, so I'm not sure what you're really getting there. It wouldn't be hard at all to write map, filter, remove, etc. in terms of list operations. Perhaps that's what you're looking for? If I understand your original complaint, you want map, filter, etc, to be eager. True, my original concern was (and my main concern still is) to avoid crashes (in this case, stack overflow errors) that stem from unexpected (to me) consequences of laziness. Those problems could indeed be solved by rewriting map and filter etc, or (easier) by wringing out the laziness wherever it arises, e.g. by forcing everything to be a vector (or a list, as you suggest). It's a little cumbersome to do this everywhere, though, and I was wondering if there was an existing library or approach for this issue. Then, however, it was suggested that I could have my cake and another kind of cake too, by using reducers. The suggestion was that this could banish the laziness-related issues while also providing significant performance improvements. Sounds good to me! I'm still working on getting my current project to behave well using reducers, but it seems promising. On the other hand, time spent learning how lazy seqs work, and the caveats involved will make it easier for you to understand the code produced by the rest of the community. So perhaps that's the better option. I agree that it's important to understand lazy sequences, and I do think I understand the core concepts reasonably well (and I've implemented lazy evaluation in other languages, etc.). But I've also traced some really annoying and hard to find bugs to unexpected (and sometimes never fully explained) consequences of laziness, so I'd like to find the best ways to avoid it when I don't really want it. If that best way turns out to make things run faster too then that'd be fantastic. -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Eval-ing a map expression in Emacs Live doesn't seem to work
I opened a core.clj file in my Emacs Live and, to make sure everything is working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used cider-jack-in to get a repl connection. For practice I entered this: (map #(+ % 5) [1 2 3 4 5]) ... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e The output was: = [1 2 3 4 5] ... instead of the expected [6 7 8 9 10] ?? gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Eval-ing a map expression in Emacs Live doesn't seem to work
Maybe you evaluated the inner vector instead of the outer expression? Might depend whether your cursor is on or after the last paren. On Wednesday, June 4, 2014 6:32:18 PM UTC-5, g vim wrote: I opened a core.clj file in my Emacs Live and, to make sure everything is working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used cider-jack-in to get a repl connection. For practice I entered this: (map #(+ % 5) [1 2 3 4 5]) ... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e The output was: = [1 2 3 4 5] ... instead of the expected [6 7 8 9 10] ?? gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Eval-ing a map expression in Emacs Live doesn't seem to work
Your cursor was probably on the closing paren at the end - you eval'd the previous expression, which was the vector. Check out the key bindings here: https://github.com/clojure-emacs/cider#cider-mode If your cursor is anywhere on that expression, you probably want C-c C-c. On Wed, Jun 4, 2014 at 7:32 PM, gvim gvi...@gmail.com wrote: I opened a core.clj file in my Emacs Live and, to make sure everything is working, pressed Ctrl-c Ctrl-l to make sure it's loaded. I also used cider-jack-in to get a repl connection. For practice I entered this: (map #(+ % 5) [1 2 3 4 5]) ... then moved to the end of the s-expression and pressed Ctrl-x Ctrl-e The output was: = [1 2 3 4 5] ... instead of the expected [6 7 8 9 10] ?? gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Effective Clojure book?
Are there any books yet that prescribe best practices for Clojure, à la Meyers or Bloch? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Effective Clojure book?
《The joy of clojure》 ? 2014-06-05 9:30 GMT+08:00 Mike Fikes mikefi...@me.com: Are there any books yet that prescribe best practices for Clojure, à la Meyers or Bloch? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What's clojure killer app? I don't see any.
Jony, Hey thanks Just finish watching and reading about Gorilla-Repl (will be digging deeper) and WOW really clean and simple UI -Nice. Much Much easier to install than IPython notebook was and its Clojure! Couldn't follow much of your coding as I said I am just starting out. I like the keystrokes and no buttons - I do need to remap chrome-browser ctrl-g to something else -don't use it anyway. I like how you can show the underling 'value' of things. Couldn't this type of application run remotely and potentially provide a 'live work space' for dislocated groups of students? Maybe a keystroke that toggles screen control. - a 'kitchen table coders' thing but virtual. -just a thought. I really am convinced that clojure is a great first language to learn- and I'm determined to learn it. Thanks -Doug On Tuesday, June 3, 2014 6:54:31 AM UTC-4, Jony Hudson wrote: On Monday, 2 June 2014 18:42:32 UTC+1, douglas smith wrote: A killer app for me and I think MANY others like me would be very similar to a Kovas' 'Session' 'pretty like Light Table' and beefy like IPythons Notebooks. Hope you'll excuse a shameless plug, but have you seen Gorilla REPL ( http://gorilla-repl.org) ? It may or may not have some of the things you're looking for :-) Jony -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is it the right Clojure group for a newbie
On Tuesday, June 3, 2014 8:41:33 AM UTC-5, Gregg Reynolds wrote: I know you've asked for online resources, but I can't resist a plug for The Little Schemer http://mitpress.mit.edu/books/little-schemer. It's short, very clear, starts at the very beginning, and you don't even need a computer to read it. (It's also annoyingly cute, but you can overlook that with a little effort.) It's far and away the best introduction I've ever come across to the kind of thinking one needs to master in order to program in lispy languages like Clojure. It uses scheme, but everything translates more or less directly to Clojure. I'll second Gregg's recommendation, especially given your comment that you're coming from a non-technical background. This book will get you into a good mindset for Clojure programming. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Past and future of data.generators
clojure.core provides a minimal set of functions for random effects: rand, rand-int, and rand-nth, currently with no simple ability to base these on a resettable random number generator or on different RNGs in different threads. (But see this ticket http://dev.clojure.org/jira/browse/CLJ-1420 pointed out by Andy Fingerhut in another thread.) data.generators includes additional useful general-purpose functions involving random numbers and random choices, but this is entirely not obvious when you read the docstrings. (Some of the docstrings are pretty mysterious.) It's also not necessarily what one would guess from the name of the library. (None of this is a criticism of anyone or anything about the project. Data.generators is at an 0.n.m release stage. I'm very grateful for the work that people have put in on it.) As I understand it, data.generators was split off from test.generative, which sounds like a good idea.So data.generators was intended to provide functions that generate random data for testing. (I imagine that the existing documentation makes more sense in the context of test.generative, too.) However, what's in data.generator has more general applications, for people who want random numbers, samples, etc. outside of software testing. (In my case, that would be for random effects in scientific simulations.) Off the top of my head, it seems to me that these other applications might have slightly different needs from the use of data.generators by test.generative. For one thing, efficiency might matter a lot in some simulations, but not in software testing. (At least, *I* wouldn't care if my test functions were slow.) I'm not saying that functions in data.generator are slow, but I don't think there's a good reason to worry about making them efficient if they're only intended for software testing. Further, there are other needs than are currently provided by test.generators. See the sampling functions in bigml/sampling https://github.com/bigmlcom/sampling or Incanter http://incanter.org/, for example, and lots of other random functions that Incanter provides. Some of those should remain in Incanter, of course, but I wonder whether Clojure would benefit from a contributed library that satisfied a set of core needs for random effects. (Incanter partly builds on clojure.core's rand at this point.) Maybe data.generators is/will be that library. Or maybe parts of data.generators would make more sense as part of a separate library (math.random? data.random? math.probability?) that could be split out of data.generators. (If it doesn't make sense to split data.generators, then would a new name for the library be more appropriate?) Just some things I was wondering about. Curious to see what others say. (Fun tip: Check out data.generators' anything function, which is like Emacs' Zippy the Pinhead functions for people who prefer industrial atonal music composed by randomly filtered Jackson Pollock paintings, to speech. Or: People who want to thoroughly test their functions by throwing random randomly-typed data at them.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
