Re: Compilation model
you can use the *compile-files* flag if you need to differentiate compiling versus running contexts. This will be useful if you use AOT to create class files for later packaging. This flag is useful to avoid global code chunks to run when they create side effects (runtime inits, ...). You do not want these to occur at compile time if you expect to package a jar file. This applies to the JVM Clojure implementation (and probably CLR). The flag allows to you avoid executing code at compilation time but it will not allow you to create compile time definitions that will disappear at runtime as there's no fence between these . It's a convenience to postpone code execution. I did not dig much in the JS clojure implementation yet. I suspect there's no need for this, the compiler being external to the runtime and there's no runtime eval (well a very restricted runtime sexpr serialization feature). In this implementation, there's a clean split between these two contexts from what I know at this point. Luc P. Hi all, I had a question about clojure's compilation model, which my co-worker suggest to redirect here :-) I wonder what clojure does during compilation of a file? Can side-effects occur (definition of variables, functions, macros, etc in the compiler)? Does clojure have an EVAL-WHEN construct for specifying compile-time evaluations, or is there a convention for splitting code across different source files? And then, how does this tie in to a module system? Thanks in advance for any information or references :-) Yong -- You 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 -- Softaddictslprefonta...@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
Call for Presentations: Commercial Users of Functional Programming 2012
The 2012 CUFP call for presentations is out: http://cufp.org/cufp-2012-call-presentations The program committee is hoping for better representation from the Clojure community this year, so if you've got something interesting to say about Clojure, please submit a proposal! --Chouser -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
Mamet Ipsum
http://mametipsum.herokuapp.com/ I wrote this to teach myself Clojure. The code is on GitHub: https://github.com/tvaughan/mametipsum. Thanks for Clojure. I enjoyed it. Any comments are appreciated. -Tom -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
One implementation using only one recursive function and the sequence library: (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) pieces (partition-all len 1 sequence) [fst rst] (split-with #(not= mark %) pieces) fst(map first fst) rst(map first (drop len rst))] (remove empty? (lazy-seq (list* fst (split-at-subsequence mark rst))) I've created https://gist.github.com/1901772 for the code. Hope this helps, Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
Maybe this version is clearer: (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) pieces (partition-all len 1 sequence) [fst rst] (split-with #(not= mark %) pieces) head (map first fst) rst-input (map first (drop len rst)) tail (lazy-seq (split-at-subsequence mark rst-input))] (if (empty? head) tail (list* head tail) I think it would be better to create the lazy-seq over a function that uses the pieces in order to not to explode input with partition-all and de-explode it with map-first before the recursive call. Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
One variation making the lazy-sequence only over the pieces: (defn split-at-subsequence [mark input] (let [len (count mark) split-at-subseq (fn split-at-subseq [pieces] (when (seq pieces) (let [[fst rst] (split-with #(not= mark %) pieces) head (map first fst) rst-pieces (drop len rst) tail (lazy-seq (split-at-subseq rst-pieces))] (if (empty? head) tail (list* head tail)] (when-let [sequence (seq input)] (split-at-subseq (partition-all len 1 sequence) I suppose it is better to define a private function for the computation of the lazy-sequence than define it inside the let. Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
On Fri, Feb 24, 2012 at 11:30 AM, JuanManuel Gimeno Illa jmgim...@gmail.com wrote: Maybe this version is clearer: (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) pieces (partition-all len 1 sequence) [fst rst] (split-with #(not= mark %) pieces) head (map first fst) rst-input (map first (drop len rst)) tail (lazy-seq (split-at-subsequence mark rst-input))] (if (empty? head) tail (list* head tail) I think it would be better to create the lazy-seq over a function that uses the pieces in order to not to explode input with partition-all and de-explode it with map-first before the recursive call. That hangs on the case (first (second (split-at-subsequence [1 2] (range again. I don't know why; from what I can see, it shouldn't, since everything seems sufficiently lazy. Maybe could also use some optimization: (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) pieces (partition-all len 1 sequence) step (fn step [rst-input] (when rst-input (lazy-seq (let [[fst rst] (split-with #(not= mark %) rst-input)] (cons fst (step (nthnext rst len)))] (map #(map first %) (remove nil? (map seq (step pieces))) This avoids computing len and pieces and (map first ...) over and over, and uses nthnext instead of drop to save some calls to seq. The split-with could be replaced by a loop to save traversing part of the sequence twice, but then it would definitely be impossible to fix the hang with (first (second (split-at-subsequence [1 2] (range. It's probably possible to do quite a bit better, though, perhaps by using Boyer-Moore, though I'm not sure how easily Boyer-Moore can be made lazy, especially lazy enough to avoid than hang. -- You 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
Bret Victor - Inventing on Principle
Hi Everyone, You may have seen this already, if not I believe it's worth investing 1h of your life: http://vimeo.com/36579366 That's already a good candidate for the technical talk of the year, if not the decade IMO. Ok, I'm getting a bit too enthusiastic here but this is so inspiring. After watching it, you can't help thinking that we have a whole new world to invent. As a side note, you may start thinking that a REPL is not good enough. - Personal message to Laurent Petit: please watch and start thinking about CCW 1.0 ;o) - It also feels like ClojureScript is on the right path. But, most importantly, beyond any technical consideration, the last part is a great life lesson. -- Damien Lepage http://damienlepage.com @damienlepage https://twitter.com/#!/damienlepage linkedin.com/in/damienlepage http://www.linkedin.com/in/damienlepage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 1:29 PM, Damien Lepage damienlep...@gmail.com wrote: Hi Everyone, You may have seen this already, if not I believe it's worth investing 1h of your life: http://vimeo.com/36579366 That's already a good candidate for the technical talk of the year, if not the decade IMO. What is it with people these days and using videos for stuff that could be far better posted as text? A talk can inherently be presented as text, perhaps HTML with a few inline images if there are slides. And text (or HTML) has some HUGE advantages: * Download size is kilobytes, not gigabytes * Can be viewed on dialup, mobile, etc. without stuttering, not working at all, costing an arm and a leg, or etc. * Google can find it by the full content of the talk, not just what few keywords someone slaps onto the video's youtube page plus the inanities added by the inevitable swarm of troll commenters. * You can search in it yourself with ctrl-F in your browser. * You can skim it. * If you're a fast reader, you can probably read it and comprehend it all in less than an hour. * You can navigate in it very easily, using normal scrolling, search, and other browser tools, and see where you're going while you scroll, rather than having to drag a tiny little thingy across a tiny little seek bar blind, drop it, and then wait 40 seconds while a little wheel spins for the Flash player to *maybe* jump to the spot in the video, whereupon you will repeat the process a few times with ever finer adjustments; but the player might hang or snap back to where it was or crash instead. * You can keep a copy for offline viewing without needing: a) hacking tools to bypass the attempts by the popular video sites to be streaming-only, b) one or another big bloated piece of media player software that will steal file associations at inconvenient and random times, and c) a shitload of disk space. * No extra plugins etc. needed to view it that guzzle CPU and memory, crash at inconvenient times, and the like. You can view it in Lynx (minus the slides, if any) if you want to. You can view it on a 286 with no graphics card (not no 3D card, no graphics, period, just 80x24 text mode). You can view it on your old Commodore 64 with 300 baud modem if you want to and it won't take sixty thousand years to download on that either. * You can copy and paste bits of it into a snippets file or whatever, if there's bits you want to refer back to later that gave you technical ideas. Or print it out and apply hiliter to key passages. Or etc. * If you're blind you can still get screen-reader software to read it for you. If you're deaf, on the other hand, a video is quite likely to be completely useless, since streaming framerates and lip-reading don't tend to mix and none of these things seem to be closed-captioned. * Text is easy and cheap to mirror widely around the net and relatively easy to translate to other languages. Video can be hosted free at only a handful of sites and is more work to translate. What does video get you that text or HTML+images couldn't get you? * You can hear what the guy's voice actually sounds like. * You get to see a talking head bobbing around and lips moving in a jerky, stuttery sort of way. * You get the pronunciation, but not the spelling, of the obscure technical/latin words that get used, instead of the other way 'round. * There can be full-motion video demonstrations of things. Not worth what you lose, IMO, even if you aren't deaf, and especially if you are. Full-motion video demonstrations can be separate short videos embedded in a text+images web page. Oh, and by the way, your post doesn't even bother to actually say what, exactly, the talk is about. It implies strongly that it has something to do with interactive development tools, and it's clear that something in it wowed you, but that's it, and the URL itself is completely opaque. Apparently the only way to find out in more detail what the talk's topic is is to click the link, at minimum, and maybe you even have to play the video part-way. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Are you Ken Wesson with a new account? On Fri, Feb 24, 2012 at 1:00 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 1:29 PM, Damien Lepage damienlep...@gmail.com wrote: Hi Everyone, You may have seen this already, if not I believe it's worth investing 1h of your life: http://vimeo.com/36579366 That's already a good candidate for the technical talk of the year, if not the decade IMO. What is it with people these days and using videos for stuff that could be far better posted as text? A talk can inherently be presented as text, perhaps HTML with a few inline images if there are slides. And text (or HTML) has some HUGE advantages: * Download size is kilobytes, not gigabytes * Can be viewed on dialup, mobile, etc. without stuttering, not working at all, costing an arm and a leg, or etc. * Google can find it by the full content of the talk, not just what few keywords someone slaps onto the video's youtube page plus the inanities added by the inevitable swarm of troll commenters. * You can search in it yourself with ctrl-F in your browser. * You can skim it. * If you're a fast reader, you can probably read it and comprehend it all in less than an hour. * You can navigate in it very easily, using normal scrolling, search, and other browser tools, and see where you're going while you scroll, rather than having to drag a tiny little thingy across a tiny little seek bar blind, drop it, and then wait 40 seconds while a little wheel spins for the Flash player to *maybe* jump to the spot in the video, whereupon you will repeat the process a few times with ever finer adjustments; but the player might hang or snap back to where it was or crash instead. * You can keep a copy for offline viewing without needing: a) hacking tools to bypass the attempts by the popular video sites to be streaming-only, b) one or another big bloated piece of media player software that will steal file associations at inconvenient and random times, and c) a shitload of disk space. * No extra plugins etc. needed to view it that guzzle CPU and memory, crash at inconvenient times, and the like. You can view it in Lynx (minus the slides, if any) if you want to. You can view it on a 286 with no graphics card (not no 3D card, no graphics, period, just 80x24 text mode). You can view it on your old Commodore 64 with 300 baud modem if you want to and it won't take sixty thousand years to download on that either. * You can copy and paste bits of it into a snippets file or whatever, if there's bits you want to refer back to later that gave you technical ideas. Or print it out and apply hiliter to key passages. Or etc. * If you're blind you can still get screen-reader software to read it for you. If you're deaf, on the other hand, a video is quite likely to be completely useless, since streaming framerates and lip-reading don't tend to mix and none of these things seem to be closed-captioned. * Text is easy and cheap to mirror widely around the net and relatively easy to translate to other languages. Video can be hosted free at only a handful of sites and is more work to translate. What does video get you that text or HTML+images couldn't get you? * You can hear what the guy's voice actually sounds like. * You get to see a talking head bobbing around and lips moving in a jerky, stuttery sort of way. * You get the pronunciation, but not the spelling, of the obscure technical/latin words that get used, instead of the other way 'round. * There can be full-motion video demonstrations of things. Not worth what you lose, IMO, even if you aren't deaf, and especially if you are. Full-motion video demonstrations can be separate short videos embedded in a text+images web page. Oh, and by the way, your post doesn't even bother to actually say what, exactly, the talk is about. It implies strongly that it has something to do with interactive development tools, and it's clear that something in it wowed you, but that's it, and the URL itself is completely opaque. Apparently the only way to find out in more detail what the talk's topic is is to click the link, at minimum, and maybe you even have to play the video part-way. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group,
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool 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
Re: Bret Victor - Inventing on Principle
What does video get you that text or HTML+images couldn't get you? watching the video would answer the question and would have probably taken you less time than writing this email... Not worth what you lose, IMO how can you know if you haven't watched the video? -- Marco Abis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
El viernes 24 de febrero de 2012 18:46:03 UTC+1, Cedric Greevey escribió: On Fri, Feb 24, 2012 at 11:30 AM, JuanManuel Gimeno Illa wrote: I think it would be better to create the lazy-seq over a function that uses the pieces in order to not to explode input with partition-all and de-explode it with map-first before the recursive call. That hangs on the case (first (second (split-at-subsequence [1 2] (range again. I don't know why; from what I can see, it shouldn't, since everything seems sufficiently lazy. My third version does this and I think does not hang on the example. Maybe could also use some optimization: (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) pieces (partition-all len 1 sequence) step (fn step [rst-input] (when rst-input (lazy-seq (let [[fst rst] (split-with #(not= mark %) rst-input)] (cons fst (step (nthnext rst len)))] (map #(map first %) (remove nil? (map seq (step pieces))) This avoids computing len and pieces and (map first ...) over and over, and uses nthnext instead of drop to save some calls to seq. The split-with could be replaced by a loop to save traversing part of the sequence twice, but then it would definitely be impossible to fix the hang with (first (second (split-at-subsequence [1 2] (range. What I don't understand of your solution is the (map seq (step pieces)) because for me it is clear that each of the sequences generated by step is a seq, so why do you need to seq it? It's probably possible to do quite a bit better, though, perhaps by using Boyer-Moore, though I'm not sure how easily Boyer-Moore can be made lazy, especially lazy enough to avoid than hang. Interesting Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:13 PM, Marco Abis marco.a...@gmail.com wrote: What does video get you that text or HTML+images couldn't get you? watching the video would answer the question and would have probably taken you less time than writing this email... Actually, it would have taken an hour, and writing the email took much less. Not worth what you lose, IMO how can you know if you haven't watched the video? Because it was described as a talk. That means the bulk of the actually meaningful content in it comes from someone's lips flapping. That can be rendered as text, easily. If there are slides, ... but I've already been over all of that. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
nah it's possible i guess, but he's the only other person i've ever seen type an essay about it on this forum in reply to someone posting a link to a video. also, he posts and yours are very similar and he disappeared shortly before you arrived. AND YOU WOULD HAVE GOT AWAY WITH IT IF IT WASNT FOR THOSE MEDDLING KIDS!! On Fri, Feb 24, 2012 at 1:12 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
First: sorry, my reply was meant to be sent to you only, not the list Actually, it would have taken an hour, and writing the email took much less. ... Because it was described as a talk. That means the bulk of the actually meaningful content in it comes from someone's lips flapping. That can be rendered as text, easily. If there are slides, ... but I've already been over all of that. you are wrong, watch the video first -- Marco Abis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
On Fri, Feb 24, 2012 at 2:17 PM, JuanManuel Gimeno Illa jmgim...@gmail.com wrote: What I don't understand of your solution is the (map seq (step pieces)) because for me it is clear that each of the sequences generated by step is a seq, so why do you need to seq it? It's the combination of (remove nil? (map seq ...)) that gets rid of the empty seqs in cases like (split-at-subsequence [3 4] [1 2 3 4 3 4 5 6]). I don't know if it's any more efficient than (remove empty? ...) though. But if the inner loop were modified so no empty seqs that weren't already nil could be generated, it could be reduced to just (remove nil? ...) and be more efficient then. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:19 PM, Marco Abis marco.a...@gmail.com wrote: First: sorry, my reply was meant to be sent to you only, not the list Because it was described as a talk. That means the bulk of the actually meaningful content in it comes from someone's lips flapping. That can be rendered as text, easily. If there are slides, ... but I've already been over all of that. you are wrong, No, I am *not* wrong. A talk can be translated into text+embeds with very little or nothing being lost, almost by definition. It might be the case that the OP was wrong when he described the video in question as a talk, but that's a completely different matter. Regardless, I highly doubt that there's anywhere close to 60 minutes of video in there that couldn't be better presented in some other way. Most likely, it would be better as text and a few short video segments, the latter adding up to much less than 60 minutes in duration. watch the video No. A full hour is way, way too long for something analogous to a blog post or a mailing list message, and I have lots of other demands on my time. (As for gaz's conspiracy theory, I won't even dignify that with a separate response.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:12 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool support? Surely it's possible that you've never heard of Ken Wesson, he disappeared right before you joined, you respond to emails in the same manner, you share the same opinions. Seems legit, Ken. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:25 PM, Jay Fields j...@jayfields.com wrote: On Fri, Feb 24, 2012 at 2:12 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool support? Surely it's possible that you've never heard of Ken Wesson, he disappeared right before you joined, you respond to emails in the same manner, you share the same opinions. Seems legit, Ken. If it is you, Ken, welcome back ;) I'm no doubt in the minority, but I've actually kind of missed your postings. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:25 PM, Jay Fields j...@jayfields.com wrote: On Fri, Feb 24, 2012 at 2:12 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool support? Surely it's possible that you've never heard of Ken Wesson, he disappeared right before you joined, you respond to emails in the same manner, you share the same opinions. Seems legit, Ken. OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
Why would you (remove nil? (map f coll))? That's what keep is for: (keep f coll). On Feb 24, 11:20 am, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:17 PM, JuanManuel Gimeno Illa jmgim...@gmail.com wrote: What I don't understand of your solution is the (map seq (step pieces)) because for me it is clear that each of the sequences generated by step is a seq, so why do you need to seq it? It's the combination of (remove nil? (map seq ...)) that gets rid of the empty seqs in cases like (split-at-subsequence [3 4] [1 2 3 4 3 4 5 6]). I don't know if it's any more efficient than (remove empty? ...) though. But if the inner loop were modified so no empty seqs that weren't already nil could be generated, it could be reduced to just (remove nil? ...) and be more efficient then. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
On Fri, Feb 24, 2012 at 2:43 PM, Alan Malloy a...@malloys.org wrote: Why would you (remove nil? (map f coll))? That's what keep is for: (keep f coll). Why would you (remove nil? (map f coll))? Because you didn't know about keep, obviously. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
@cedric: I think you've made your point. I know you're not asking for advice, but I think the constructive thing would have been to ask: Could you please provide more context? Are there slides available of this talk? If you want to rant about this newfangled video contraption, this list is not the place. '(Devin Walters) On Friday, February 24, 2012 at 1:13 PM, Marco Abis wrote: What does video get you that text or HTML+images couldn't get you? watching the video would answer the question and would have probably taken you less time than writing this email... Not worth what you lose, IMO how can you know if you haven't watched the video? -- Marco Abis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On 02/24/2012 02:42 PM, Cedric Greevey wrote: On Fri, Feb 24, 2012 at 2:25 PM, Jay Fields j...@jayfields.com wrote: On Fri, Feb 24, 2012 at 2:12 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool support? Surely it's possible that you've never heard of Ken Wesson, he disappeared right before you joined, you respond to emails in the same manner, you share the same opinions. Seems legit, Ken. OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. https://groups.google.com/d/msg/clojure/0kCwGrFU5zs/NGclkY46fvEJ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Bringing this back on topic, I watched the video. Wow! was it worth it. This guy has some pretty mind-blowing demos. I highly recommend this, I'm going to have to sit down soon and code up a clone of his binary search tree demo. Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:51 PM, Daniel E. Renfer duck112...@gmail.com wrote: On 02/24/2012 02:42 PM, Cedric Greevey wrote: OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. Most of us on this list probably have strong opinions -- it tends to go with the territory of being smarter than the average bear. As for hating videos where text will do, need I repeat my list of bullet points again? It's quite *obvious*. It's no more surprising for multiple techies to find videos-where-text-will-do to be a troubling trend than for techies to find that Lisps and even Algols are nicer languages to program large systems in than Visual Basic. :) Especially since we techies are very used to using search tools and other things specifically geared around finding *text*, and often have multiple devices including mobile where bandwidth costs can quickly become exorbitant. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Perhaps someone will volunteer to transcribe it and post that. You know, maybe someone who can type quickly and prefers text. :-) I've done that for one of Rich's earlier talks posted as video. It takes time, and I'm not volunteering for this one. Andy On Feb 24, 2012, at 11:57 AM, Cedric Greevey wrote: On Fri, Feb 24, 2012 at 2:51 PM, Daniel E. Renfer duck112...@gmail.com wrote: On 02/24/2012 02:42 PM, Cedric Greevey wrote: OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. Most of us on this list probably have strong opinions -- it tends to go with the territory of being smarter than the average bear. As for hating videos where text will do, need I repeat my list of bullet points again? It's quite *obvious*. It's no more surprising for multiple techies to find videos-where-text-will-do to be a troubling trend than for techies to find that Lisps and even Algols are nicer languages to program large systems in than Visual Basic. :) Especially since we techies are very used to using search tools and other things specifically geared around finding *text*, and often have multiple devices including mobile where bandwidth costs can quickly become exorbitant. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
I need a braille version, any volunteer ? BTWY, what was the initial subject of this thread ? I'm half-joking here, welcome back Mr Wesson. : Mr Smith Perhaps someone will volunteer to transcribe it and post that. You know, maybe someone who can type quickly and prefers text. :-) I've done that for one of Rich's earlier talks posted as video. It takes time, and I'm not volunteering for this one. Andy On Feb 24, 2012, at 11:57 AM, Cedric Greevey wrote: On Fri, Feb 24, 2012 at 2:51 PM, Daniel E. Renfer duck112...@gmail.com wrote: On 02/24/2012 02:42 PM, Cedric Greevey wrote: OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. Most of us on this list probably have strong opinions -- it tends to go with the territory of being smarter than the average bear. As for hating videos where text will do, need I repeat my list of bullet points again? It's quite *obvious*. It's no more surprising for multiple techies to find videos-where-text-will-do to be a troubling trend than for techies to find that Lisps and even Algols are nicer languages to program large systems in than Visual Basic. :) Especially since we techies are very used to using search tools and other things specifically geared around finding *text*, and often have multiple devices including mobile where bandwidth costs can quickly become exorbitant. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Softaddictslprefonta...@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
Re: Bret Victor - Inventing on Principle
Sorry, I certainly didn't intend to start such a heated debate ;o) Hopefully some of you appreciate the link but you're all free to ignore. The truth is, no matter the media, there are too many interesting things and you need to choose. I had this video in my todo list for a week before I took the time to watch it. After that, I thought it was kind of special and worth sharing, any textual representation would betray its essence in my opinion. 2012/2/24 Andy Fingerhut andy.finger...@gmail.com Perhaps someone will volunteer to transcribe it and post that. You know, maybe someone who can type quickly and prefers text. :-) I've done that for one of Rich's earlier talks posted as video. It takes time, and I'm not volunteering for this one. Andy On Feb 24, 2012, at 11:57 AM, Cedric Greevey wrote: On Fri, Feb 24, 2012 at 2:51 PM, Daniel E. Renfer duck112...@gmail.com wrote: On 02/24/2012 02:42 PM, Cedric Greevey wrote: OK. I googled the group archives. Seems there was a Ken Wesson active on the list for a while, but he disappeared a couple of months before I joined. I'm not sure why people think I might be him. Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. Most of us on this list probably have strong opinions -- it tends to go with the territory of being smarter than the average bear. As for hating videos where text will do, need I repeat my list of bullet points again? It's quite *obvious*. It's no more surprising for multiple techies to find videos-where-text-will-do to be a troubling trend than for techies to find that Lisps and even Algols are nicer languages to program large systems in than Visual Basic. :) Especially since we techies are very used to using search tools and other things specifically geared around finding *text*, and often have multiple devices including mobile where bandwidth costs can quickly become exorbitant. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Damien Lepage http://damienlepage.com @damienlepage https://twitter.com/#!/damienlepage linkedin.com/in/damienlepage http://www.linkedin.com/in/damienlepage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Feb 24, 2012, at 1:51 PM, Daniel E. Renfer wrote: Ken Wesson was noted for having strong opinions as was a noted hater of videos where text will do. He was also the only guy who would post replies with just you're welcome as the body. Until Cedric, that is... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Envoyé de mon iPhone Le 24 févr. 2012 à 19:29, Damien Lepage damienlep...@gmail.com a écrit : Hi Everyone, You may have seen this already, if not I believe it's worth investing 1h of your life: http://vimeo.com/36579366 That's already a good candidate for the technical talk of the year, if not the decade IMO. Ok, I'm getting a bit too enthusiastic here but this is so inspiring. After watching it, you can't help thinking that we have a whole new world to invent. As a side note, you may start thinking that a REPL is not good enough. - Personal message to Laurent Petit: please watch and start thinking about CCW 1.0 ;o) - Hello Damien, I had already watched the first half of the talk. I found the live demonstrations rather impressive, indeed. I've since wondered how this could be generalized, which does not seem that easy. Anyway, certainly a fun and entertaining goal to achieve ! Think about playing with overtone that way, for example ... Also, sorry for you that your original question has been totally high jacked by someone how's not even taken the time to understand what you were talking about before starting his generalized rant. Maybe not for CCW 1.0, but for 2.0, who knows ? Anyway, Cedric the self-described smarter than average guy, please note that, as usual, patches are welcome ;-) It also feels like ClojureScript is on the right path. But, most importantly, beyond any technical consideration, the last part is a great life lesson. -- Damien Lepage http://damienlepage.com @damienlepage https://twitter.com/#!/damienlepage linkedin.com/in/damienlepage http://www.linkedin.com/in/damienlepage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
This solution, I think, does not do more map first than needed, avoids computing len and pieces more than once, uses nthnext to avoid extra cost of drop and computes the example (first (second (split-at-subsequence [1 2] (range (defn split-at-subsequence [mark input] (when-let [sequence (seq input)] (let [len (count mark) partition (partition-all len 1 sequence) step (fn step [pieces] (when pieces (let [[fst rst] (split-with #(not= mark %) pieces) tail (lazy-seq (step (nthnext rst len)))] (if (empty? fst) tail (list* (map first fst) tail)] (step partition It works, but some little modifications of it which I think should work, do not. For instance, if we move the lazy-seq just before the let of the inner function, stops working. I need to work more on lazy sequences :-) Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
On Fri, Feb 24, 2012 at 2:19 PM, Marco Abis marco.a...@gmail.com wrote: First: sorry, my reply was meant to be sent to you only, not the list Because it was described as a talk. That means the bulk of the actually meaningful content in it comes from someone's lips flapping. That can be rendered as text, easily. If there are slides, ... but I've already been over all of that. you are wrong, No, I am *not* wrong. A talk can be translated into text+embeds with very little or nothing being lost, almost by definition. It might be the case that the OP was wrong when he described the video in question as a talk, but that's a completely different matter. Regardless, I highly doubt that there's anywhere close to 60 minutes of video in there that couldn't be better presented in some other way. Most likely, it would be better as text and a few short video segments, the latter adding up to much less than 60 minutes in duration. watch the video No. A full hour is way, way too long for something analogous to a blog post or a mailing list message, and I have lots of other demands on my time. Hi, My real name is Stuart Halloway, and I have the ability to remove people from this mailing list. People who continue off-topic debates about the merits of video vs. text will be removed. Let's get back to Clojure. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Thanks for posting the link. I've been following Bret Victor's blog and the stuff he has been doing for some time. Bret has built some very impressive UIs using OpenLaszlo, and he is a fan of the technology and the expressiveness of the LZX language for building UIs. OpenLaszlo was created by bunch of smart folks and Lispers, including Oliver Steele (worked for Apple on Dylan), Max Carlson, Tucker Withington (worked for Symbolics and Harlequin, implemented the GC for Dylan when Apple hired Harlequin to work on the language), and Henry Minsky (Marvin Minsky's son). http://osteele.com/ http://pt.withy.org/ Here's an old gestural zoom/pan demo Bret built with OpenLaszlo: http://worrydream.com/GesturalZoomAndPan/ OpenLaszlo's LZX language uses a declarative approach to building UIs and highly interactive applications (check this video of the Laszlo Dashboard, which was created in 2002/2003 http://vimeo.com/14206607). LZX is a mixture of XML tags + JavaScript, which initially was compiled into SWF bytecode. In 2007 Laszlo added cross-compilation to JavaScript (DHTML runtime) to the platform, and in 2009 cross-compilation to ActionScript 3 (which is then compiled into SWF using the Flex SDK). Here's a video of the LzPix application, the first OpenLaszlo app to cross-compile to JavaScript http://vimeo.com/32853986 My technology dream-team for client development would be ClojureScript combined with OpenLaszlo (has a powerful view kernel with interesting stuff like constraints, datapath mapping using xpath, simple yet powerful animation APIs). Instead of using XML + JavaScript, I'd prefer to use a more Clojure/Lisp like syntax to build UIs with OpenLaszlo in combination with ClojureScript. There's a slight chance that we can get the OpenLaszlo Lisp folks interested in integrating OpenLaszlo with ClojureScript (they are all working at Nest Labs now), and I'm sure that Bret Victor would love the combination as a tool for building some awesome prototypes. - Raju -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Thanks for bringing the discussion back on track. That's a great list of contexts links. David On Fri, Feb 24, 2012 at 4:27 PM, Raju Bitter rajubit...@googlemail.comwrote: Thanks for posting the link. I've been following Bret Victor's blog and the stuff he has been doing for some time. Bret has built some very impressive UIs using OpenLaszlo, and he is a fan of the technology and the expressiveness of the LZX language for building UIs. OpenLaszlo was created by bunch of smart folks and Lispers, including Oliver Steele (worked for Apple on Dylan), Max Carlson, Tucker Withington (worked for Symbolics and Harlequin, implemented the GC for Dylan when Apple hired Harlequin to work on the language), and Henry Minsky (Marvin Minsky's son). http://osteele.com/ http://pt.withy.org/ Here's an old gestural zoom/pan demo Bret built with OpenLaszlo: http://worrydream.com/GesturalZoomAndPan/ OpenLaszlo's LZX language uses a declarative approach to building UIs and highly interactive applications (check this video of the Laszlo Dashboard, which was created in 2002/2003 http://vimeo.com/14206607). LZX is a mixture of XML tags + JavaScript, which initially was compiled into SWF bytecode. In 2007 Laszlo added cross-compilation to JavaScript (DHTML runtime) to the platform, and in 2009 cross-compilation to ActionScript 3 (which is then compiled into SWF using the Flex SDK). Here's a video of the LzPix application, the first OpenLaszlo app to cross-compile to JavaScript http://vimeo.com/32853986 My technology dream-team for client development would be ClojureScript combined with OpenLaszlo (has a powerful view kernel with interesting stuff like constraints, datapath mapping using xpath, simple yet powerful animation APIs). Instead of using XML + JavaScript, I'd prefer to use a more Clojure/Lisp like syntax to build UIs with OpenLaszlo in combination with ClojureScript. There's a slight chance that we can get the OpenLaszlo Lisp folks interested in integrating OpenLaszlo with ClojureScript (they are all working at Nest Labs now), and I'm sure that Bret Victor would love the combination as a tool for building some awesome prototypes. - Raju -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
That's a great talk, and a great basic principle: that creators need an immediate connection to their creation. I realized this has also been my side project for the last few months, though mostly in hammock phase. I think the foundational technology we need, as a community, is an html5 repl. You type code into the browser, and can create output that takes advantage of the host's capabilities - graphics, video, UI etc. The problem is a bit more multifaceted then just html though, as it also involves UI state, persisting the sessions, how to share/reuse the creations, and the general problem of UI description in the context of clojurescript. But where this gets you is this: a clojure interaction environment based on web standards, rather than narrow dialects like elisp and swing. So the lines between programming clojure, extending the clojure programming environment, and deploying webapps goes away. It's possible to see a line between this category of tool, and the demos in the presentation. If the game is tightly coupling data, code, and complex visual representation, we have the building blocks to bust that game wide open. It makes no sense to build on a platform other than the web, and IMHO the big step there is to program clojure from the web, to produce fully-active web content. Another aspect of immediate connection, and one not mentioned in the talk, is the social aspect. You make things, and show them to people, get feedback, see things others have made. Now imagine if the clojure community was creating in a system that is inherently web based. Many interesting things could be built on that. On Fri, Feb 24, 2012 at 4:27 PM, Raju Bitter rajubit...@googlemail.com wrote: Thanks for posting the link. I've been following Bret Victor's blog and the stuff he has been doing for some time. Bret has built some very impressive UIs using OpenLaszlo, and he is a fan of the technology and the expressiveness of the LZX language for building UIs. OpenLaszlo was created by bunch of smart folks and Lispers, including Oliver Steele (worked for Apple on Dylan), Max Carlson, Tucker Withington (worked for Symbolics and Harlequin, implemented the GC for Dylan when Apple hired Harlequin to work on the language), and Henry Minsky (Marvin Minsky's son). http://osteele.com/ http://pt.withy.org/ Here's an old gestural zoom/pan demo Bret built with OpenLaszlo: http://worrydream.com/GesturalZoomAndPan/ OpenLaszlo's LZX language uses a declarative approach to building UIs and highly interactive applications (check this video of the Laszlo Dashboard, which was created in 2002/2003 http://vimeo.com/14206607). LZX is a mixture of XML tags + JavaScript, which initially was compiled into SWF bytecode. In 2007 Laszlo added cross-compilation to JavaScript (DHTML runtime) to the platform, and in 2009 cross-compilation to ActionScript 3 (which is then compiled into SWF using the Flex SDK). Here's a video of the LzPix application, the first OpenLaszlo app to cross-compile to JavaScript http://vimeo.com/32853986 My technology dream-team for client development would be ClojureScript combined with OpenLaszlo (has a powerful view kernel with interesting stuff like constraints, datapath mapping using xpath, simple yet powerful animation APIs). Instead of using XML + JavaScript, I'd prefer to use a more Clojure/Lisp like syntax to build UIs with OpenLaszlo in combination with ClojureScript. There's a slight chance that we can get the OpenLaszlo Lisp folks interested in integrating OpenLaszlo with ClojureScript (they are all working at Nest Labs now), and I'm sure that Bret Victor would love the combination as a tool for building some awesome prototypes. - Raju -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.java.jmx 0.1 - problem getiing java.lang:type=Threading :AllThreadIds attribute
I had a look at the java.jmx code and worked out and tested s simple
fix:
diff --git a/src/main/clojure/clojure/java/jmx.clj b/src/main/clojure/
clojure/java/jmx.clj
index 128e516..3d291a3 100644
--- a/src/main/clojure/clojure/java/jmx.clj
+++ b/src/main/clojure/clojure/java/jmx.clj
@@ -203,9 +203,16 @@
(into-array (map name attrs)
(.getAttribute *connection* (as-object-name n) (name attrs
+(defn- array-chk
+ Check if v is Java array and if so, convert it to vector
+ [v]
+ (if (.isArray (class v))
+(vec v)
+v))
+
(def ^{:doc Read one or more mbean properties.}
read
- (comp objects-data raw-read))
+ (comp array-chk objects-data raw-read))
user= (require '[clojure.java.jmx :as jmx])
nil
user= (jmx/read java.lang:type=Threading :AllThreadIds)
[11 10 6 3 2 1]
This also makes sure that values returned by read and mbean functions
are immutable.
On Feb 24, 3:32 am, Nick Bailey nickmbai...@gmail.com wrote:
I'm not sure that java.jmx should be attempting to do any conversion
of the values returned over jmx. I think it should be the
application's responsibility to convert types appropriately for how
they are needed.
On Wed, Feb 22, 2012 at 7:47 PM, zoka ztomi...@gmail.com wrote:
I was trying to convert result of JMX attributes query to JSON, and
encountered problem while reading one particular attribute value of
java.lang:type=Threading. Here is the REPL transcript:
demo.server= (require '[clojure.java.jmx :as jmx])
nil
demo.server= (jmx/read java.lang:type=Threading :AllThreadIds)
#long[] [J@1bd97d0d
demo.server=
This seems to be Java long array reference,
The jmx/mbean function that returns all attribute name as keywords
associated with their values carries this value through. Attempt to
convert such map to JSON string causes exception, since in this case
a clojure vector of longs would be expected instead of Java array.
This particular piece information (list of application ThreadIs) is
not of particular interest to me anyway, so it is easy just to remove
the offending map entry as a workaround.
I have noticed some recent activity in clojure.java.jmx github repo,
so I thought it would be appropriate to rise this issue, since it may
be affecting some other attributes as well.
Regards
Zoka
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: [ANN] Luke VanderHart's Clojure Zippers Conj video up
I've finally signed and scanned my video release, for my short talk on Cascade. http://dl.dropbox.com/u/39927208/conj-video-release.pdf On Mon, Dec 27, 2010 at 10:08 AM, Alan Dipert a...@dipert.org wrote: Hi everyone, We've just released the next Conj video, Luke VanderHart's talk on Clojure Zippers: http://clojure.blip.tv/file/4503162/ I've also just blogged over at clojure.com on what our video release plan is, along with links to videos released so far: http://clojure.com/blog/2010/12/27/conj-videos.html The source for all videos Clojure is still http://clojure.blip.tv/, and if you'd like to know the moment the next video is available, be sure to follow clojure_conj on Twitter: http://twitter.com/clojure_conj Thank you, and Happy Holidays, Alan and the Clojure/core team -- You 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 -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clj-blueprints
I'd like to present you with an small library for working with Blueprints-enabled graph databases in Clojure: https://github.com/eduardoejp/clj-blueprints Have fun! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Hi, this video showed up on my G+ stream about a week ago and it was /fun/ to watch. I think most of the people around here will be more intrigued by the first half, which has a focus on programming. Side-note: this is one of the (few) video presentations that just can't be translated to text. Wait for the slider in the browser game... However, I digress... Am Freitag, 24. Februar 2012 21:34:54 UTC+1 schrieb lpetit: Hello Damien, I had already watched the first half of the talk. I found the live demonstrations rather impressive, indeed. I've since wondered how this could be generalized, I may be wrong, but I as far as I understand the message of the video it is explicitly not about generalization. It's more about finding a niche of programming where you can make the experience of the person doing things more direct. Thus, I'd rather consider the particular situation of a person doing UI-stuff with seesaw or doing web-stuff with ring and friends or whatever, the direct thing. I think Overtone does a lot right from this point of view. But then again, the niche may be programmers writing pure functions and the example of the video may apply. After all this has been said, of course I may have misunderstood your remark about generalization, Laurent. Kind regards, Stefan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
That's a nice summary, and is part of what I'm hoping to enable with nREPL.[1] I started with it trying to provide a tool-agnostic REPL backend, but I quickly wanted to get past the rigid text orientation of that medium. Yes, Clojure forms are always read as text, and that's the dominant medium of interaction used by programmers everywhere, but it doesn't (and maybe shouldn't) be that way. Certainly, the leverage provided by well-executed, relevant, perhaps-interactive visualizations is becoming widely appreciated; I don't see why we should allow our programming practice to be segregated in a text ghetto when different mediums are better — or necessary. Anyway, nREPL has developed to the point where middlewares can be written to easily offer richer representations of data within the REPL. An example of my earliest (primitive!) experiments around this are available here[2]. Images and other data flowing through a REPL isn't a _huge_ deal, except that: * nREPL is tool-agnostic; reply (and therefore Leiningen v2) or vimclojure or jark or textmate or sublime text can elect to receive those other representations, and present them to the user however is appropriate * nREPL is transport-agnostic; the default socket transport (bencode[3] with some particular semantics) is very lightweight, and can receive or transmit binary data efficiently (a distinct advantage compared to shipping textual encodings of such data in e.g. s-expressions). A proof of concept of a tty transport is included in nREPL (so you could connect to an nREPL backend using something as meager as telnet), and I have a sketch of an nREPL ring handler that I'll get out on github soon. This should allow you to easily drop an nREPL endpoint into any ring app, connect to it with any HTTP or nREPL client, and do anything you'd like to do in a REPL without tunneling, mucking around with ssh tunnels, and taking advantage of all existing webapp security regime you have in place. And, if you have the right middlewares in place and a suitably-capable client, rich representations of REPL data and rich interactions with the same should be within arm's reach. I have less of a vision for the HTML5 side of things. I'm certain a killer in-browser nREPL client could be put together to take advantage of all of the above, whether it's connecting to an HTTP nREPL endpoint or a (web)socket transport using nREPL's wire protocol, but I'm personally more interested on thick clients (perhaps embedding webviews as necessary!) for various reasons. FYI, for anyone working on tooling to help support things like this, I'd invite you to join the clojure-tools group I created recently: http://groups.google.com/group/clojure-tools/browse_thread/thread/48ff47ab5d7ca2c?hl=en Cheers, - Chas [1] http://github.com/clojure/tools.nrepl [2] http://cemerick.com/2011/10/26/enabling-richer-interactions-in-the-clojure-repl/ [3] It turns out that bencode and the way nREPL uses it seems similar to but much simpler than Google's SPDY protocol. On Feb 24, 2012, at 5:33 PM, kovas boguta wrote: That's a great talk, and a great basic principle: that creators need an immediate connection to their creation. I realized this has also been my side project for the last few months, though mostly in hammock phase. I think the foundational technology we need, as a community, is an html5 repl. You type code into the browser, and can create output that takes advantage of the host's capabilities - graphics, video, UI etc. The problem is a bit more multifaceted then just html though, as it also involves UI state, persisting the sessions, how to share/reuse the creations, and the general problem of UI description in the context of clojurescript. But where this gets you is this: a clojure interaction environment based on web standards, rather than narrow dialects like elisp and swing. So the lines between programming clojure, extending the clojure programming environment, and deploying webapps goes away. It's possible to see a line between this category of tool, and the demos in the presentation. If the game is tightly coupling data, code, and complex visual representation, we have the building blocks to bust that game wide open. It makes no sense to build on a platform other than the web, and IMHO the big step there is to program clojure from the web, to produce fully-active web content. Another aspect of immediate connection, and one not mentioned in the talk, is the social aspect. You make things, and show them to people, get feedback, see things others have made. Now imagine if the clojure community was creating in a system that is inherently web based. Many interesting things could be built on that. On Fri, Feb 24, 2012 at 4:27 PM, Raju Bitter rajubit...@googlemail.com wrote: Thanks for posting the link. I've been following Bret Victor's blog and the stuff he has been doing for some time. Bret has built
Re: lazyness
Try this (you need to wrap the return val of helper in lazy-seq also): (defn pair-sequences-by ([seq-1 seq-2 f1 f2] s1 and s2 are guaranteed to be strictly monotonically increasing whith respect to f1 and f2 as keys respectively. The return value is pairs of elements e1 from s1 and e2 from s2 such that (= (f1 e1) (f2 e2)) is true (let [helper (fn helper [s1 s2] (loop [[x xs :as wx] s1 [y ys :as wy] s2] (when (and x y) (let [[xk yk] (map #(%1 %2) [f1 f2] [x y])] (let [cval (compare xk yk)] (cond ( cval 0) (recur xs wy) (= cval 0) (cons [x y] (lazy-seq (helper xs ys))) ( cval 0) (recur wx ys)))] (lazy-seq (helper seq-1 seq-2 ([seq-1 seq-2 f] (pair-sequences-by seq-1 seq-2 f f))) On Fri, Feb 24, 2012 at 11:36 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Everybody, Can somebody comment if the following piece of code is truely lazy? (defn pair-sequences-by ([seq-1 seq-2 f1 f2] s1 and s2 are guaranteed to be strictly monotonically increasing whith respect to f1 and f2 as keys respectively. The return value is pairs of elements e1 from s1 and e2 from s2 such that (= (f1 e1) (f2 e2)) is true (let [helper (fn helper [s1 s2] (loop [[x xs :as wx] s1 [y ys :as wy] s2] (when (and x y) (let [[xk yk] (map #(%1 %2) [f1 f2] [x y])] (let [cval (compare xk yk)] (cond ( cval 0) (recur xs wy) (= cval 0) (cons [x y] (helper xs ys)) ( cval 0) (recur wx ys)))] (lazy-seq (helper seq-1 seq-2 ([seq-1 seq-2 f] (pair-sequences-by seq-1 seq-2 f f))) https://gist.github.com/e9f6c0ad9bbe535d2d54 I am running out of ram when I use this.. so any help would be greatly appreciated. Thanks, Sunil. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bret Victor - Inventing on Principle
Why listen to music when you could read lyrics? Watching a well-performed talk is about making an emotional connection with the storyteller. Go read the I have a dream speech, then watch the video. They're both powerful, but the performance trumps the script. (Please don't troll me on the example, I'm not making a comparison between speakers :) On Fri, Feb 24, 2012 at 11:12 AM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Feb 24, 2012 at 2:06 PM, gaz jones gareth.e.jo...@gmail.com wrote: Are you Ken Wesson with a new account? Who? Wait. Surely you don't think that it's not possible for more than one person to prefer text to video as a way of disseminating verbal information over the internet, given all of text's advantages in such areas as bandwidth, cost, and tool 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 -- Sam Ritchie, Twitter Inc 703.662.1337 @sritchie09 (Too brief? Here's why! http://emailcharter.org) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
use require of repl-created namespace throws exception (?)
If you create a namespace with associated vars interactively in the repl, and subsequently try to use that functionality in other namspaces with clojure.core/use, an exception is thrown: FileNotFoundException Could not locate cljsh/docs__init.class or cljsh/docs.clj on classpath: clojure.lang.RT.load (RT.java:430) I can understand that no file can be located as there is none… clojure.core/require throws the same exception (as it seems to use the same clojure.core/load-libs under the cover). Stand-alone, clojure.core/refer does work, however. If I read the docs for clojure.core/require, it is clear that it has to do with loading of code in files. However, from a usability point of view, wouldn't it make more sense to let clojure.core/require just return nil and do nothing if the namespace is already loaded (unless the :reload option is give). Not sure why require actually checks without any :reload directive… if the namespace is already loaded, and the associated lib-files can be found, it's not supposed to do anything anyway, if I understand it well. Or maybe I miss some of the subtleties between a lib and a namespace as concepts and implementations (?). -Confusingly yours, FrankS. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: lazyness
Thanks Mark, I think that worked!! Sunil. On Sat, Feb 25, 2012 at 10:54 AM, Mark Rathwell mark.rathw...@gmail.comwrote: Try this (you need to wrap the return val of helper in lazy-seq also): (defn pair-sequences-by ([seq-1 seq-2 f1 f2] s1 and s2 are guaranteed to be strictly monotonically increasing whith respect to f1 and f2 as keys respectively. The return value is pairs of elements e1 from s1 and e2 from s2 such that (= (f1 e1) (f2 e2)) is true (let [helper (fn helper [s1 s2] (loop [[x xs :as wx] s1 [y ys :as wy] s2] (when (and x y) (let [[xk yk] (map #(%1 %2) [f1 f2] [x y])] (let [cval (compare xk yk)] (cond ( cval 0) (recur xs wy) (= cval 0) (cons [x y] (lazy-seq (helper xs ys))) ( cval 0) (recur wx ys)))] (lazy-seq (helper seq-1 seq-2 ([seq-1 seq-2 f] (pair-sequences-by seq-1 seq-2 f f))) On Fri, Feb 24, 2012 at 11:36 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Everybody, Can somebody comment if the following piece of code is truely lazy? (defn pair-sequences-by ([seq-1 seq-2 f1 f2] s1 and s2 are guaranteed to be strictly monotonically increasing whith respect to f1 and f2 as keys respectively. The return value is pairs of elements e1 from s1 and e2 from s2 such that (= (f1 e1) (f2 e2)) is true (let [helper (fn helper [s1 s2] (loop [[x xs :as wx] s1 [y ys :as wy] s2] (when (and x y) (let [[xk yk] (map #(%1 %2) [f1 f2] [x y])] (let [cval (compare xk yk)] (cond ( cval 0) (recur xs wy) (= cval 0) (cons [x y] (helper xs ys)) ( cval 0) (recur wx ys)))] (lazy-seq (helper seq-1 seq-2 ([seq-1 seq-2 f] (pair-sequences-by seq-1 seq-2 f f))) https://gist.github.com/e9f6c0ad9bbe535d2d54 I am running out of ram when I use this.. so any help would be greatly appreciated. Thanks, Sunil. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
