Re: [ANN]: cljsh & repls 1.6.0 - so many repls, so little time…
On Wed, Feb 1, 2012 at 3:39 AM, Frank Siebenlist wrote: > We already have swank, lein repl, cake, nrepl, detour, clj, reply, … and now > we have the combo "cljsh & repls". > > "repls" is a lein plugin, which is essentially leiningen's native "lein repl" > task with some default config options for the (not-)printing of eval results > and repl-prompt. It gives you a persistent repl-server that uses the basic > repl-protocol: clj-code as text for the reader thru stdin, and evaluated > results and printed side-effects thru stdout. Install it with "lein plugin > install lein-repls 1.6.0", and run the repl-server in your project directory > with "lein repls", and just leave it running... > > "cljsh" is a "clojure shell" bash-script that uses "socat" under the covers > to make the repl-server's stdin and stdout appear local to cljsh. It allows > for a relatively simple sending of clj-statements and clj-files to the > persistent repl-server. cljsh is also very lightweight, like cake/nailgun, > with a negligible startup time, which makes the evaluation of much of your > clj-code almost instant. You run cljsh like a normal shell script, like bash > or sed, and pass clj-code statements and files as command line directives or > piped-in thru stdin. That code is sent to the persistent repl-server, and the > printed results and output are available on cljsh's stdout. Almost sounds too > simple… Download the cljsh script from github: > "https://raw.github.com/franks42/lein-repls/master/bin/cljsh.sh"; and put it > somewhere in your path. An example command line invocation looks like: > > $ cljsh -c '(println "hello")' > hello > $ > > or a more contrived example: > > $ cat third.clj | cljsh -c '(println "first")' -i second.clj - fourth.clj > -myargs > > The cljsh-test.sh script shows most of the supported features: > "https://github.com/franks42/lein-repls/blob/master/bin/cljsh-test.sh";. > > cljsh also supports an interactive repl-mode with history and completion > support thru rlwrap - pretty much like the other repls, except that this one > starts-up instantly, and you can have multiple, concurrent repl-sessions > working with the same persistent repl-server. (not sure why you would do > that… but you can/could… ;-)). The completion words can easily be updated > with cljsh to reflect the evaluation context, but remember that rlwrap is a > poor-man's completion solution… even though it works pretty well most of the > time. > > Possible usage scenarios. > Easy to write cljsh-scripts that can be used to select code in any text > editor or any app and send for evaluation. Select any symbol in any > app/browser and lookup the doc. Use growl notification to show you the doc or > the stack trace or eval result. Write your clj-based unix filter. Browse the > filesystem with fs by changing the repl-prompt to reflect your cwd. Write > your clj-based macosx automation service. Please let me know if you come up > with any others… > > Even though it all seems to work pretty well on my macosx… your mileage may > vary on the other unixes, and it most probably won't work on windows… maybe > cygwin(?). Please let me know of any compatibilty issues. > > Next step: extend it to support clojurescript. (…driving a browser UI thru > unix-style filters and scripts from the command line…) > > Please take a look at the README at: "https://github.com/franks42/lein-repls"; > for details. > Any feedback is very much appreciated. > > Enjoy, FrankS. Just tried it. This is what I have in Ubuntu petr@host:~$ lein repls Exception in thread "main" java.lang.Exception: Couldn't connect (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:5440) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$eval_opt.invoke(main.clj:235) at clojure.main$initialize.invoke(main.clj:254) at clojure.main$script_opt.invoke(main.clj:270) at clojure.main$main.doInvoke(main.clj:354) at clojure.lang.RestFn.invoke(RestFn.java:457) at clojure.lang.Var.invoke(Var.java:377) at clojure.lang.AFn.applyToHelper(AFn.java:172) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: java.lang.Exception: Couldn't connect at leiningen.repls$poll_repl_connection.invoke(repls.clj:129) at leiningen.repls$repls.invoke(repls.clj:184) at leiningen.repls$repls.invoke(repls.clj:155) at clojure.lang.Var.invoke(Var.java:361) at clojure.lang.AFn.applyToHelper(AFn.java:159) at clojure.lang.Var.applyTo(Var.java:482) at clojure.core$apply.invoke(core.clj:540) at leiningen.core$apply_task.invoke(core.clj:260) at leiningen.core$_main.doInvoke(core.clj:325) at clojure.lang.RestFn.invoke(RestFn.java:410) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.RestFn.apply
Re: Learning and feedback on code
On 02/03/2012 12:34 AM, Alex Baranosky wrote: Hi Manuel, Your second version looks pretty solid: https://bitbucket.org/manuelp/geo-quiz/src/a75d57d0e5a2/src/geo_quiz/core.clj You might consider getting rid of the vars for capitals, ask-capital, and ask-capitals and using a let or letfn instead. Thank you very much for your feedback Alex! Sorry for the late response, I was sick. I've incorporated your suggestions, now the short program is even shorter. Nice! Using letfn to encapsulate functions used only by quiz probably is a good strategy. For binding both vars and functions, what's preferred? Using only let for both: (let [capitals [...] ask-capital (fn [] ...) ...) or instead let coupled with letfn? (let [capitals [...]] (letfn [(ask-capitals [...)) You don't need a do inside of ask-capital. Yes it's not needed, but as I see it this way it's more explicit about side effects. As I've read in books and clojuredocs this special form is particularly well suited to this cases. Another thing I see off hand is a huge nitpick on my part is that it is not idiomatic to use: (question :country) ... (:country question) is much more the norm. I wasn't aware of this, thank you :) Best, Alex Thanks again, 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
[ANN] slacker 0.6.1 released
Hi all, Slacker 0.6.1 has been pushed to clojars. Slacker is an RPC framework designed for clojure. In 0.6.1, HA cluster coordinated by zookeeper is just supported. https://github.com/sunng87/slacker -- Sun Ning Software developer Nanjing, China (N32°3'42'' E118°46'40'') http://about.me/sunng/bio -- You 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: mixins/multiple inheritance
It sounds like a use for the decorator pattern, or am I missing something? In case I am not I have given it a shot using records and protocols: (defrecord TextField [text]) (defrecord DatetimePicker [datetimes]) (defrecord Label [text widget]) (defprotocol Renderable (render [this])) (extend-protocol Renderable TextField (render [this] (str "[" (:text this) "]")) DatetimePicker (render [this] (apply str (:datetimes this))) Label (render [this] (str (:text this) ": " (render (:widget this) (comment (def textfield (TextField. "Foo")) (def datetimepicker (DatetimePicker. [:yesterday :today :tomorrow])) (def labeledtextfield (Label. "Name" textfield)) (def labeleddatetimepicker (Label. "Date" datetimepicker)) (render textfield) ;=> [Foo] (render datetimepicker) ;=> :yesterday:today:tomorrow (render labeledtextfield) ;=> Name: [Foo] (render labeleddatetimepicker) ;=> Date: :yesterday:today:tomorrow ) 1/ is handled by the Renderable implementation of Label calling the Renderable implementation of whatever widget is decorated by the Label instance. 2/ is handled by having the label decorator as a record. Regards, Matthias On 5 Feb., 22:15, Razvan Rotaru wrote: > Hi, > > I found some posts about this topic, but they did not clarify things > in my head well enough, so I have to start my own... :) > > I'm basically craving for multiple inheritance or mixins, at least > with my current way of thinking. I haven't really gone deep enough > with multimethods or protocols, so I might be a little off track by > looking for multiple inheritance. > > Let's take an example: > > I want to implement some gui widgets, so there's a main method > "render" which draws the widget on the screen. I want to have two > types: > > - Textfield > - Datetimepicker > > Each can be "mixed" with the Label widget, so that we have: > > - LabelledTextfield > - LabelledDatetimepicker > > So, two challenges occur: > 1/ the render method for Label needs to call the render method for > it's "mixed" widget (either Textfield or Datetimepicker) - let's > assume that labels are rendered "around" the actual widget, so that we > have a simple way to mix the implementations of render method > 2/ the Label widget comes with its own data (the label text) > > For the second thing, I think it will work with defrecords, since the > label can be a map entry which can be stored in the actual widget, > even if it's not mixed with Label. I still want to point this out in > case there are other ways of achieving this. > > How can I achieve 1? Are there alternatives for 2? > > Thanks for reading, > Razvan -- You 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: mixins/multiple inheritance
It sounds a little like the decorator pattern would do the trick for you in this case - am I missing something? In case I am not, I have given it a shot using records and protocols: (defrecord TextField [text]) (defrecord DatetimePicker [datetimes]) (defrecord Label [text widget]) (defprotocol Renderable (render [this])) (extend-protocol Renderable TextField (render [this] (str "[" (:text this) "]")) DatetimePicker (render [this] (apply str (:datetimes this))) Label (render [this] (str (:text this) ": " (render (:widget this) (comment (def textfield (TextField. "Foo")) (def datetimepicker (DatetimePicker. [:yesterday :today :tomorrow])) (def labeledtextfield (Label. "Name" textfield)) (def labeleddatetimepicker (Label. "Date" datetimepicker)) (render textfield) ;=> [Foo] (render datetimepicker) ;=> :yesterday:today:tomorrow (render labeledtextfield) ;=> Name: [Foo] (render labeleddatetimepicker) ;=> Date: :yesterday:today:tomorrow ) 1/ is handled by the Renderable implementation for Label calling the Renderable implementation on whatever widget it decorates with a label. 2/ is handled by having the Label decorator widget as a record. Regards, Matthias On 5 Feb., 22:15, Razvan Rotaru wrote: > Hi, > > I found some posts about this topic, but they did not clarify things > in my head well enough, so I have to start my own... :) > > I'm basically craving for multiple inheritance or mixins, at least > with my current way of thinking. I haven't really gone deep enough > with multimethods or protocols, so I might be a little off track by > looking for multiple inheritance. > > Let's take an example: > > I want to implement some gui widgets, so there's a main method > "render" which draws the widget on the screen. I want to have two > types: > > - Textfield > - Datetimepicker > > Each can be "mixed" with the Label widget, so that we have: > > - LabelledTextfield > - LabelledDatetimepicker > > So, two challenges occur: > 1/ the render method for Label needs to call the render method for > it's "mixed" widget (either Textfield or Datetimepicker) - let's > assume that labels are rendered "around" the actual widget, so that we > have a simple way to mix the implementations of render method > 2/ the Label widget comes with its own data (the label text) > > For the second thing, I think it will work with defrecords, since the > label can be a map entry which can be stored in the actual widget, > even if it's not mixed with Label. I still want to point this out in > case there are other ways of achieving this. > > How can I achieve 1? Are there alternatives for 2? > > Thanks for reading, > Razvan -- You 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: Attn: clj-time users - possible breaking change being considered!
On Feb 5, 7:31 pm, Sean Corfield wrote: > and there's no > easy / obvious way to create a formatter with the default timezone, > without dropping down to the underlying Java. Not that I want to weaken my own case, but isn’t there? What about: (formatter "fmtstr" (default-time-zone)) ? That said, I still support/request the described change. Thanks! Avi -- You 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
ClojureScript {:optimizations :advanced}
Hey,
I'm starting to get the hang of Clojure(Script) and I'm really enjoying it.
I'd love to use it for a project but I have one major concern: How reliable
is {:optimizations :advanced}?
Advanced Compilation basically wins the whole argument for clojurescript
but I managed to break it on a very simple project. I assume it broke
because I tried to use jQuery and didnt stick to the closure library. The
only reason I wanted to jQuery is because I'm very familiar with it (and
javascript itself for that matter) and basically know nothing about
closure, but I did some (rtfm closure) and managed to get it working
without jQuery. Turns out you really dont need it.
So is it a fair assumption that as long as I stick to Closure Library + any
ClojureScript itself I'm good on the :advanced part? I'm not interested in
node.js as a :target, only the Browser. Falling back to {:optimizations
:simple} really is not an option since the resulting javascript is way too
big.
Cheers,
/thomas
PS:
My Experiments with jQuery:
http://www.zilence.net/cljs/index-dev.html
http://www.zilence.net/cljs/index-simple.html
http://www.zilence.net/cljs/index-advanced.html
https://github.com/thheller/cljs-experiments/blob/master/src-jquery/jqtest/app.cljs
The App is pointless and only tested in Chrome (firefox/ie dont like
input[type='range']) but it should update the the input when you move the
slider and update the slider when you change the input. dev/simple work
fine, advanced breaks with some undebuggable error. I assume because the
compiler optimized something away.
The Closure Version:
http://www.zilence.net/cljs/index-closure-advanced.html
https://github.com/thheller/cljs-experiments/blob/master/src-closure/ctest/app.cljs
Basically the same amount of code, so no reason to use jQuery. But I'd
still be interested to know why the jQuery version breaks.
--
You 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: Learning and feedback on code
On Mon, Feb 6, 2012 at 12:33 PM, Manuel Paccagnella wrote: > For binding both vars and functions, what's preferred? Using only let for > both: > > (let [capitals [...] > ask-capital (fn [] ...) > ...) > > or instead let coupled with letfn? > > (let [capitals [...]] > (letfn [(ask-capitals [...)) I'd usually just use let. The only advantage that I know of to naming local functions with letfn is that you can put mutually recursive functions in letfn, or, more generally, functions that refer to one another in a circular manner. With plain let, functions later in the let can refer to ones earlier in the let but not vice versa so you can manage by putting them in the right order if there aren't any circularities but you need letfn if there are circularities (barring ugly hacks involving atoms or similar). -- You 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: ClojureScript {:optimizations :advanced}
In short, yes, if you stick to gClosure, advanced compilation will
work fine. Closure advanced compilation is an optimizing compilation
that minifies names and removes dead (unused, uncalled) code. Trying
to use jQuery without special effort will result in calls to jQuery
being unaddressable. There is a nice writeup on including external
javascript with ClojureScript and the Closure compiler at [1]. Also,
jayq has an externs file for advanced compilation with jQuery 1.7 at
[2].
[1] http://lukevanderhart.com/2011/09/30/using-javascript-and-clojurescript.html
[2] https://github.com/ibdknox/jayq/blob/master/resources/externs/jquery.js
On Sun, Feb 5, 2012 at 11:39 AM, Thomas Heller wrote:
> Hey,
>
> I'm starting to get the hang of Clojure(Script) and I'm really enjoying it.
> I'd love to use it for a project but I have one major concern: How reliable
> is {:optimizations :advanced}?
>
> Advanced Compilation basically wins the whole argument for clojurescript but
> I managed to break it on a very simple project. I assume it broke because I
> tried to use jQuery and didnt stick to the closure library. The only reason
> I wanted to jQuery is because I'm very familiar with it (and javascript
> itself for that matter) and basically know nothing about closure, but I did
> some (rtfm closure) and managed to get it working without jQuery. Turns out
> you really dont need it.
>
> So is it a fair assumption that as long as I stick to Closure Library + any
> ClojureScript itself I'm good on the :advanced part? I'm not interested in
> node.js as a :target, only the Browser. Falling back to {:optimizations
> :simple} really is not an option since the resulting javascript is way too
> big.
>
> Cheers,
> /thomas
>
> PS:
>
> My Experiments with jQuery:
> http://www.zilence.net/cljs/index-dev.html
> http://www.zilence.net/cljs/index-simple.html
> http://www.zilence.net/cljs/index-advanced.html
> https://github.com/thheller/cljs-experiments/blob/master/src-jquery/jqtest/app.cljs
>
> The App is pointless and only tested in Chrome (firefox/ie dont like
> input[type='range']) but it should update the the input when you move the
> slider and update the slider when you change the input. dev/simple work
> fine, advanced breaks with some undebuggable error. I assume because the
> compiler optimized something away.
>
> The Closure Version:
> http://www.zilence.net/cljs/index-closure-advanced.html
> https://github.com/thheller/cljs-experiments/blob/master/src-closure/ctest/app.cljs
>
> Basically the same amount of code, so no reason to use jQuery. But I'd still
> be interested to know why the jQuery version breaks.
>
> --
> You 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: Attn: clj-time users - possible breaking change being considered!
On Sun, Feb 5, 2012 at 5:23 PM, Avi Flax wrote: > What about: (formatter "fmtstr" (default-time-zone)) ? Ah yes, but if that's the normal desired behavior that's an ugly default compared to (formatter "fmtstr")... Also worth noting is that Avi pointed out that (now), (today-at-midnight), (epoch) etc all use UTC instead of the default time zone so this is a broader philosophical point of whether clj-time should continue to use UTC as its default or your default time zone. I tend to have all my servers set to UTC and do everything in UTC (and then convert for input / output into the local user's timezone) so I'm perfectly happy with clj-time as it stands. This is more about whether the majority of users would prefer the current UTC behavior or whether it would be more convenient to use the (local) default time zone? Currently folks would need (to-time-zone (now) (default-time-zone)) and similar calls. If the behavior was changed, folks who wanted UTC would need (to-time-zone (now) utc) - although for many of these calls I'd probably add an optional timezone argument to support (now utc). Hmm, that might be worthwhile anyway to allow (now (default-time-zone))... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You 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: ClojureScript {:optimizations :advanced}
More externs files here:
http://code.google.com/p/closure-compiler/source/browse/#svn%2Ftrunk%2Fcontrib%2Fexterns
I imagine that the CJLS community will provide something similar for
useful, popular JavaScript libraries not covered well by CLJS, Closure, or
CLJS libs.
David
On Mon, Feb 6, 2012 at 1:56 PM, Mark Rathwell wrote:
> In short, yes, if you stick to gClosure, advanced compilation will
> work fine. Closure advanced compilation is an optimizing compilation
> that minifies names and removes dead (unused, uncalled) code. Trying
> to use jQuery without special effort will result in calls to jQuery
> being unaddressable. There is a nice writeup on including external
> javascript with ClojureScript and the Closure compiler at [1]. Also,
> jayq has an externs file for advanced compilation with jQuery 1.7 at
> [2].
>
> [1]
> http://lukevanderhart.com/2011/09/30/using-javascript-and-clojurescript.html
> [2]
> https://github.com/ibdknox/jayq/blob/master/resources/externs/jquery.js
>
> On Sun, Feb 5, 2012 at 11:39 AM, Thomas Heller
> wrote:
> > Hey,
> >
> > I'm starting to get the hang of Clojure(Script) and I'm really enjoying
> it.
> > I'd love to use it for a project but I have one major concern: How
> reliable
> > is {:optimizations :advanced}?
> >
> > Advanced Compilation basically wins the whole argument for clojurescript
> but
> > I managed to break it on a very simple project. I assume it broke
> because I
> > tried to use jQuery and didnt stick to the closure library. The only
> reason
> > I wanted to jQuery is because I'm very familiar with it (and javascript
> > itself for that matter) and basically know nothing about closure, but I
> did
> > some (rtfm closure) and managed to get it working without jQuery. Turns
> out
> > you really dont need it.
> >
> > So is it a fair assumption that as long as I stick to Closure Library +
> any
> > ClojureScript itself I'm good on the :advanced part? I'm not interested
> in
> > node.js as a :target, only the Browser. Falling back to {:optimizations
> > :simple} really is not an option since the resulting javascript is way
> too
> > big.
> >
> > Cheers,
> > /thomas
> >
> > PS:
> >
> > My Experiments with jQuery:
> > http://www.zilence.net/cljs/index-dev.html
> > http://www.zilence.net/cljs/index-simple.html
> > http://www.zilence.net/cljs/index-advanced.html
> >
> https://github.com/thheller/cljs-experiments/blob/master/src-jquery/jqtest/app.cljs
> >
> > The App is pointless and only tested in Chrome (firefox/ie dont like
> > input[type='range']) but it should update the the input when you move the
> > slider and update the slider when you change the input. dev/simple work
> > fine, advanced breaks with some undebuggable error. I assume because the
> > compiler optimized something away.
> >
> > The Closure Version:
> > http://www.zilence.net/cljs/index-closure-advanced.html
> >
> https://github.com/thheller/cljs-experiments/blob/master/src-closure/ctest/app.cljs
> >
> > Basically the same amount of code, so no reason to use jQuery. But I'd
> still
> > be interested to know why the jQuery version breaks.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Attn: clj-time users - possible breaking change being considered!
On Mon, Feb 6, 2012 at 2:09 PM, Sean Corfield wrote: > Also worth noting is that Avi pointed out that (now), > (today-at-midnight), (epoch) etc all use UTC instead of the default > time zone so this is a broader philosophical point of whether clj-time > should continue to use UTC as its default or your default time zone. I > tend to have all my servers set to UTC and do everything in UTC (and > then convert for input / output into the local user's timezone) so I'm > perfectly happy with clj-time as it stands. This is more about whether > the majority of users would prefer the current UTC behavior or whether > it would be more convenient to use the (local) default time zone? Maybe there should be a *switch* for 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: Attn: clj-time users - possible breaking change being considered!
On Mon, Feb 6, 2012 at 11:17 AM, Cedric Greevey wrote: > Maybe there should be a *switch* for that ... A good suggestion as a possible compromise to allow both defaults. Right now, my default position is to not change anything unless enough folks indicate a desire for default time zone per Avi's suggestion. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You 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: mixins/multiple inheritance
Thanks, This works, but there's a problem: the labeledtextfield is not a textfield anymore, it's a label. Therefore it does not behave like a textfield (which implements other protocols as well). I need multiple inheritance, in one way or another. I've been trying to find a way to implement with multimethods. For example, if label was a mixin, then it means I could do something like this: (def textfield (new TextField "Foo") (def labeledtextfield (new (mix TextField Label) "Name" "Foo")) (render textfield) ;=> [Foo] (render labeledtextfield) ;=> Name: [Foo] Oh, and I'd like to stay away from macros, if possible. :) Razvan On Feb 6, 12:20 pm, Matthias Diehn Ingesman wrote: > It sounds a little like the decorator pattern would do the trick for > you in this case - am I missing something? In case I am not, I have > given it a shot using records and protocols: > > (defrecord TextField [text]) > (defrecord DatetimePicker [datetimes]) > (defrecord Label [text widget]) > > (defprotocol Renderable > (render [this])) > > (extend-protocol Renderable > TextField > (render [this] > (str "[" (:text this) "]")) > > DatetimePicker > (render [this] > (apply str (:datetimes this))) > > Label > (render [this] > (str (:text this) ": " (render (:widget this) > > (comment > (def textfield (TextField. "Foo")) > (def datetimepicker (DatetimePicker. [:yesterday :today :tomorrow])) > (def labeledtextfield (Label. "Name" textfield)) > (def labeleddatetimepicker (Label. "Date" datetimepicker)) > (render textfield) ;=> [Foo] > (render datetimepicker) ;=> :yesterday:today:tomorrow > (render labeledtextfield) ;=> Name: [Foo] > (render labeleddatetimepicker) ;=> Date: :yesterday:today:tomorrow > ) > > 1/ is handled by the Renderable implementation for Label calling the > Renderable implementation on whatever widget it decorates with a > label. > > 2/ is handled by having the Label decorator widget as a record. > > Regards, > Matthias -- You 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: Learning and feedback on code
On 02/06/2012 07:08 PM, Cedric Greevey wrote: On Mon, Feb 6, 2012 at 12:33 PM, Manuel Paccagnella wrote: For binding both vars and functions, what's preferred? Using only let for both: (let [capitals [...] ask-capital (fn [] ...) ...) or instead let coupled with letfn? (let [capitals [...]] (letfn [(ask-capitals [...)) I'd usually just use let. The only advantage that I know of to naming local functions with letfn is that you can put mutually recursive functions in letfn, or, more generally, functions that refer to one another in a circular manner. With plain let, functions later in the let can refer to ones earlier in the let but not vice versa so you can manage by putting them in the right order if there aren't any circularities but you need letfn if there are circularities (barring ugly hacks involving atoms or similar). Clear explanation, thank you Cedric! -- You 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: Learning and feedback on code
On Mon, Feb 6, 2012 at 2:43 PM, Manuel Paccagnella wrote: >> The only advantage that I know of to naming >> local functions with letfn is that you can put mutually recursive >> functions in letfn, or, more generally, functions that refer to one >> another in a circular manner. With plain let, functions later in the >> let can refer to ones earlier in the let but not vice versa so you can >> manage by putting them in the right order if there aren't any >> circularities but you need letfn if there are circularities (barring >> ugly hacks involving atoms or similar). > > Clear explanation, thank you Cedric! You're welcome. -- You 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: Attn: clj-time users - possible breaking change being considered!
As Avi points out on the github issue discussion, this change would best be done throughout, i.e. wherever a DateTime instance is created, otherwise one would end up with surprising behaviour (default of UTC in date-time, default of JVM default time zone in formatter). That being said, I would argue for keeping UTC as the time zone when creating DateTime instances (including via formatter), unless another time zone is explicitly requested. Although I appreciate the argument for following Joda time in using the JVM default time zone, I think clj-time would benefit from imposing a bit of purity in this case. Using the JVM defaults for such settings always allows some unpredictability to leak into your code (default file encoding, anyone?). In other words, the value of (date-time 1970 1 1) should not, in my opinion, depend on whether it is run on my machine or yours. clj-time.core makes it's use of UTC clear in the documentation, although a heads-up regarding the departure from Joda time's behaviour in this regard would probably help prevent users tripping over the same issue Avi had. On the other hand, I sympathize with Avi that it can be somewhat inconvenient to specify times in non-UTC. from-time-zone and to-time-zone are not the most succinct way of dealing with this, in my opinion. I admit I quickly ended up writing a helper function to produce DateTime instances for explicitly named time zones. Ideally I would like to be able to pass the time zone to date-time et al. The way date-time uses multiple arities currently precludes this, but my preferred way would be to say, e.g. (date-time :utc 1970 1 1 10 30) => # or: (date-time :europe-barcelona 1970 1 1 10 30) => # or indeed: (date-time (default-time-zone) 1970 1 1 10 30) => # ; YMMV and to have UTC as a fallback when no time zone is specified: (date-time 1970 1 1 10 30) => # I personally think it is helpful to make the time zone explicit by either passing it or accecpting the constant default of UTC. Dealing with dates and time zones is a lot like dealing with bytes and encodings. While cultural, operating system or run time defaults may lull you into treating the time zone/encoding as somehow supplementary and non-essential, you don't really know the value unless you define both aspects of the data (and you will get bitten sooner or later). Ok, I'll stop before I go completely OT. Regards, Caspar -- You 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: Attn: clj-time users - possible breaking change being considered!
Good feedback Casper, thanx! On Mon, Feb 6, 2012 at 12:43 PM, Caspar Hasenclever wrote: > As Avi points out on the github issue discussion, this change would > best be done throughout, i.e. wherever a DateTime instance is created, > otherwise one would end up with surprising behaviour (default of UTC > in > date-time, default of JVM default time zone in formatter). > > That being said, I would argue for keeping UTC as the time zone when > creating > DateTime instances (including via formatter), unless another time zone > is explicitly > requested. > > Although I appreciate the argument for following Joda time in using > the JVM default > time zone, I think clj-time would benefit from imposing a bit of > purity in this case. > Using the JVM defaults for such settings always allows some > unpredictability to leak > into your code (default file encoding, anyone?). > > In other words, the value of (date-time 1970 1 1) should not, in my > opinion, depend > on whether it is run on my machine or yours. > > clj-time.core makes it's use of UTC clear in the documentation, > although a heads-up > regarding the departure from Joda time's behaviour in this regard > would probably help > prevent users tripping over the same issue Avi had. > > On the other hand, I sympathize with Avi that it can be somewhat > inconvenient to specify > times in non-UTC. from-time-zone and to-time-zone are not the most > succinct way > of dealing with this, in my opinion. I admit I quickly ended up > writing a helper function > to produce DateTime instances for explicitly named time zones. Ideally > I would like to be able > to pass the time zone to date-time et al. The way date-time uses > multiple arities currently > precludes this, but my preferred way would be to say, e.g. > > (date-time :utc 1970 1 1 10 30) > => # > > or: > (date-time :europe-barcelona 1970 1 1 10 30) > => # > > or indeed: > (date-time (default-time-zone) 1970 1 1 10 30) > => # ; YMMV > > and to have UTC as a fallback when no time zone is specified: > (date-time 1970 1 1 10 30) > => # > > I personally think it is helpful to make the time zone explicit by > either passing it or accecpting the constant default of UTC. Dealing > with dates and time zones is a lot like dealing with bytes and > encodings. > While cultural, operating system or run time defaults may lull you > into treating > the time zone/encoding as somehow supplementary and non-essential, > you don't really know the value unless you define both aspects of the > data > (and you will get bitten sooner or later). > > Ok, I'll stop before I go completely OT. > > Regards, > > Caspar -- You 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
newline question
A while back (starting with the change to 1.3?), I noticed that in Emacs, running under Windows, using the clojure-jack-in method to start a REPL within Emacs, commands like println print the newline with a ^M character. I don't have this problem in lein repl, Anyone know how I can get rid of the spurious ^M characters? Thanks, Mark -- You 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: newline question
Use linux or MacOs ? :) Luc > A while back (starting with the change to 1.3?), I noticed that in Emacs, > running under Windows, using the clojure-jack-in method to start a REPL > within Emacs, commands like println print the newline with a ^M character. > I don't have this problem in lein repl, > > Anyone know how I can get rid of the spurious ^M characters? > > Thanks, > > Mark > > -- > You 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 -- Softaddicts 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: Attn: clj-time users - possible breaking change being considered!
On Mon, Feb 6, 2012 at 3:43 PM, Caspar Hasenclever wrote: > In other words, the value of (date-time 1970 1 1) should not, in my > opinion, depend > on whether it is run on my machine or yours. This is an important, valid point. Probably I should amend my earlier suggestion from a switch that uses either UTC or the OS timezone setting to, instead, that there should be a *default-time-zone* Var that is, by default, UTC, but which you can set!, alter-var-root!, or dynamically bind to something else before/when calling into the lib if you want some other default in the no-timezone-argument versions of the functions in the lib. -- You 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: newline question
On Mon, Feb 6, 2012 at 7:48 PM, Softaddicts wrote: > Use linux or MacOs ? > > :) Or use a Windows-native editor. ;) -- You 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
cljs-143 - possible issue
I tried to comment on JIRA - but am not sure if it was accepted.
http://dev.clojure.org/jira/browse/CLJS-143
There appears to still be an issue with this in the following scenario:
(ns test
(:require
[cljs.reader :as reader]
)
)
(defn log [x]
(.log js/console (pr-str x))
x
)
(def data
{{:start 143 :end 144} "data" }
)
(log {:data data})
(doseq [k (keys data)]
(let [ks (pr-str k)
kr (reader/read-string ks)]
(log {:k k
:v (get data k)
:k-hash (hash k)
:read-k kr
:read-k-hash (hash kr)
:read-v (get data kr)}
))
)
My output:
{:data {{:end 144, :start 143} "data"}}
{:k {:end 144, :start 143}, :k-hash 40749209, :read-k {:start 143, :end
144}, :read-k-hash -1503612376, :read-v nil, :v "data"}
The patch appears to have been applied on my clojurescript install.
can this be confirmed?
Dave
--
You 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: cljs-143 - possible issue
Fixed, thanks for the report.
On Mon, Feb 6, 2012 at 10:30 PM, Dave Sann wrote:
> I tried to comment on JIRA - but am not sure if it was accepted.
>
> http://dev.clojure.org/jira/browse/CLJS-143
>
> There appears to still be an issue with this in the following scenario:
>
> (ns test
> (:require
> [cljs.reader :as reader]
> )
> )
>
> (defn log [x]
> (.log js/console (pr-str x))
> x
> )
>
> (def data
> {{:start 143 :end 144} "data" }
> )
>
> (log {:data data})
>
> (doseq [k (keys data)]
> (let [ks (pr-str k)
> kr (reader/read-string ks)]
> (log {:k k
>:v (get data k)
>:k-hash (hash k)
>:read-k kr
>:read-k-hash (hash kr)
>:read-v (get data kr)}
>
> ))
> )
>
>
> My output:
>
> {:data {{:end 144, :start 143} "data"}}
> {:k {:end 144, :start 143}, :k-hash 40749209, :read-k {:start 143, :end
> 144}, :read-k-hash -1503612376, :read-v nil, :v "data"}
>
> The patch appears to have been applied on my clojurescript install.
>
> can this be confirmed?
>
> Dave
>
>
> --
> You 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: cljs-143 - possible issue
that was fast. Nice work! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Improved apropos
I have occasionally been frustrated by the behavior of apropos because it returns a list of matching symbols, but with no clue as to which namespace those symbols are in. I wrote a couple of functions to help with this, apropos2 and unresolve. https://gist.github.com/1757414 apropos2 is like apropos, except it returns a list of symbols that include a namespace qualification, if one is needed to use the symbol from the current namespace. The symbols returned can be used in that namespace in code, or as arguments to 'doc' or 'source', unlike some of the return values from 'apropos'. unresolve is like resolve in reverse: given a Var, it constructs a list of all symbols that resolve to that Var from the current namespace. Examples of use are given below. apropos2 uses unresolve to find the shortest symbol that resolves to a given Var. Do similar functions already exist in a published library? Does anyone have bug fixes or other suggested enhancements to the code? Andy Example use of apropos2: user=> (apropos "replace") (postwalk-replace prewalk-replace replace) user=> (doc postwalk-replace) nil user=> (apropos2 "replace") (clojure.walk/prewalk-replace replace clojure.walk/postwalk-replace) user=> (use 'clojure.walk) nil user=> (apropos2 "replace") (prewalk-replace replace postwalk-replace) Example use of unresolve: user=> (unresolve #'replace) (replace clojure.core/replace) user=> (use 'clojure.string) WARNING: replace already refers to: #'clojure.core/replace in namespace: user, being replaced by: #'clojure.string/replace WARNING: reverse already refers to: #'clojure.core/reverse in namespace: user, being replaced by: #'clojure.string/reverse nil user=> (unresolve #'replace) (replace clojure.string/replace) user=> (unresolve #'clojure.core/replace) (clojure.core/replace) -- You 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: Leiningen survey results
Hi Phil, great to see these results. I've just started introducing leiningen to my students at CIID Copenhagen and think there's an answer for your disbelieving "2.0.0-SNAPSHOT" comment... If you install the 1.6.2 standalone version, lein version will report 2.0.0-SNAPSHOT. Hth! K. On 4 February 2012 07:34, Ryan Doenges wrote: > Now I want to get a patch into Leiningen so I can get a sticker! > > On Wed, Feb 1, 2012 at 3:12 PM, Phil Hagelberg wrote: >> >> I just finished up summarizing the results for the Leiningen survey I >> posted a few weeks ago. We ended up with just over 300 answers, so if >> you're interested in getting a snapshot of usage you can see it at >> http://lein-survey.herokuapp.com/results >> >> -Phil >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To 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
