Re: [ANN] Re-launching Expectations!
Great news! Looking forward to adding the support for the clojure.test protocol. CIDER's users will really appreciate it! On 6 October 2016 at 21:36, Colin Yates wrote: > Thanks Sean. > > On 6 October 2016 at 19:03, Sean Corfield wrote: > >> is there a 'benefits over clojure.test' blog anywhere? > > > > Not that I’m aware of. I added a GH issue against the website content > for that. Jay wrote a series of blog posts about Expectations back in 2011 > that included the justification for it: > > > > http://blog.jayfields.com/2011/11/clojure-expectations-introduction.html > > > >> I wonder if it is the benefits are more subjective > > > > Yes, I find the BDD-style of Expectations much more to my liking than > the assertive style of clojure.test – the latter feels very imperative to > me. So there’s definitely an element of stylistic preference at play here. > > > >> I personally like the names I give to tests etc. > > > > Jay has an opinion on that – see http://blog.jayfields.com/ > 2011/11/clojure-expectations-unit-testing-wrap.html > > > > I’m split on the topic. There’s a practical reason for giving tests > names, and that relates to tooling and, in particular, what CIDER and other > tools expect (and in fact that is what has triggered this whole > re-launching: in order to better support tooling at large, Expectations > needs to provide a way to give predictable names to tests so that tooling > can run and re-run individual tests). > > > > Sean > > > > > > > > -- > > You 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: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)
Hey, I'm glad this came up. We were initially thinking we'd wait until the API and design had stabilized before releasing Cortex, but there is enough of value now that I think Kovas is right. We should release it. Cortex has been a collaboration between ThinkTopic and Mike Anderson, and it's design is somewhat similar to Torch. (Neural network layers that implement protocols for forward computation and backward propagation of gradients along with a set of optimizers.) Although we are already using Cortex models in production, it's definitely still a library in flux. We had arrived at a pretty good set of base abstractions in pure Clojure using core.matrix, but then when we decided to add gpu support we realized we had to refactor things a bit. The CuDNN and CuBLAS libraries from Nvidia provide a lot of useful functionality, but they also come with their own abstractions for matrix computation, neural network layers, optimizers, etc. To take advantage of the GPU effectively we also need to be able to sequence and interleave tasks using streams, which requires a variety of design changes unless we want to maintain separate implementations of almost everything for both the CPU and the GPU. You can build and run networks now, but we are still exploring how this should all come together. So, as long as you keep in mind that things will change, it would be great to have you all join the conversation and help experiment with abstractions and apis. Give us a couple days to do some house keeping, and then we'll open source it. -Jeff On Thursday, October 6, 2016 at 8:08:41 PM UTC-6, kovasb wrote: > > On Thu, Oct 6, 2016 at 9:20 PM, Mikera > wrote: > >> Hi Dragan, >> >> We have things working quite well (including stuff like cuDNN integration >> for convolution networks on the GPU). We also have all of the standard >> stuff (many different layer types, dropout, noise function, regularisation >> etc.). However I think it still needs a bunch of work before we stabilise >> on the core API. >> > > >> Things I'm paricularly keen to have nailed down in particular before we >> go public: >> > > FWIW it sounds like you've achieved a huge amount already. > > There are many people in the Clojure community who can come up with a DAG > abstraction. There are very, very few who have the skill and time to assess > and integrate the various native libs necessary to achieve the fundamental > operations in a clojure-friendly way. > > If people build on the 'wrong' api, thats a good problem to have. The > field is so in flux anyway. The problem can also be mitigated through > minimalism in what is released in the beginning. > > In any case, looking forward to hopefully seeing this stuff one day. > > > > > > -- You 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.
newbee mystery
WHY? The following prints 1/n 2/n 3/n fine in the repl (for [f [1 2 3]] (println f)) But does nothing in this lein project (the "Hello World???" does print) (ns slide.core (:gen-class)) (defn -main [& args] ;; work around dangerous default behaviour in Clojure (alter-var-root #'*read-eval* (constantly false)) (for [f [1 2 3]] (println f)) (println "Hello, World??")) (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.
[ANN] Nightlight, an embedded editor for Clojure
Just when you thought I was done with my weird obsession with making projects that start with “night”, I went and made another. This one is called Nightlight, and it’s a Clojure editor with a unique twist: it is meant to run *inside* your project, giving it direct access to the state of your program. This might end up being a great idea, or an embarrassingly stupid one. Website: https://sekao.net/nightlight/ Github: https://github.com/oakes/Nightlight I’ve only been working on this for a few weeks. To explain the idea, I’ll channel Uncle Bob and give it to you in the form of a socratic dialog between myself (Z1) and myself from two weeks ago (Z2): Z2: Nightcode has a lot of crippling limitations. It has no code completion, for starters. Its instaREPL is a toy, because it only works with clojure core. Forget about refactoring support. Z1: It’s almost as if these are caused by the same core issue. Z2: Yeah almost. Anyway where was I... Z1: No, they actually are. Traditional editors and IDEs have the same basic design -- they are standalone programs, so they have to use all sorts of complicated maneuvers to understand your project. It’s a huge source of complexity. Z2: What’s the alternative? Z1: Imagine completely reversing the relationship. Instead of an external tool enveloping and running your program, what if your program ran your development tool? What if they lived in the same process? Your editor would have direct access to the state of your program, opening the doors to all sorts of interactivity. Z2: So what’s the alternative? Z1: Are you serious? I just explained it. Z2: Right. Genius! Nobody has thought of this before. Z1: Plenty of people have, but for the most part those tools are not mainstream. Various Lisp and Smalltalk tools blurred those lines. For example, DrRacket can run your code in the same Racket instance that it is running in. Z2: Doesn’t this mean if you crash your program, you crash your editor? Z1: Yeah...don’t do that. Z2: Got it. How do we build it? Should we just shoehorn Nightcode into some kind of build task, so it pops up every time you start developing a project? Z1: That would be pretty obnoxious, which I realize makes the idea more appealing to you. But consider this: if it was a totally browser-based editor, we could just run a little web server inside your project and the user could interact with it via a browser. Z2: That sounds like a lot of work. Z1: Not really. Nightcode’s editor is already browser-based, so we just need to make the rest of the interface. It should only take about a month, or even less if a large hurricane happens to slam your city in the near future, giving you nothing else to do but code and drink beer. Z2: Hah yeah that’s not going to happen. -- You 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: newbee mystery
On 9 October 2016 at 03:00, Phil Virgo wrote: > WHY? > > The following prints 1/n 2/n 3/n fine in the repl > > (for [f [1 2 3]] (println f)) > > But does nothing in this lein project (the "Hello World???" does print) > > (ns slide.core > (:gen-class)) > > (defn -main > [& args] > ;; work around dangerous default behaviour in Clojure > (alter-var-root #'*read-eval* (constantly false)) > (for [f [1 2 3]] (println f)) > (println "Hello, World??")) > The "for" macro is lazy. It only evaluates the items in the list when it's consumed. You want the "doseq" macro instead, which is used for side-effects. Incidentally, setting *read-eval* to false doesn't make clojure.core/read safe. You should always consider clojure.core/read to be unsafe for use with data from sources you don't control. Instead use something like clojure.edn/read, which is designed to be safe. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: newbee mystery
Thanks James. So the repl behaves differently from some compiled code - good to know! I don't yet know about the "safe" issues "read-eval". This came with the little template built by lein. But I'll read up on it. On Saturday, October 8, 2016 at 10:11:29 PM UTC-4, James Reeves wrote: > > > > On 9 October 2016 at 03:00, Phil Virgo > > wrote: > >> WHY? >> >> The following prints 1/n 2/n 3/n fine in the repl >> >> (for [f [1 2 3]] (println f)) >> >> But does nothing in this lein project (the "Hello World???" does print) >> >> (ns slide.core >> (:gen-class)) >> >> (defn -main >> [& args] >> ;; work around dangerous default behaviour in Clojure >> (alter-var-root #'*read-eval* (constantly false)) >> (for [f [1 2 3]] (println f)) >> (println "Hello, World??")) >> > > The "for" macro is lazy. It only evaluates the items in the list when it's > consumed. You want the "doseq" macro instead, which is used for > side-effects. > > Incidentally, setting *read-eval* to false doesn't make clojure.core/read > safe. You should always consider clojure.core/read to be unsafe for use > with data from sources you don't control. Instead use something like > clojure.edn/read, which is designed to be safe. > > - James > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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.
