RE: [ANN] tools.trace 0.7.10
Oupse 😬 I went a bit too fast on this post... sorry... Probably a sudden drop of caffein in my blood 😂 That or I did not screw my head properly this morning 🤪🔨👈 Thank you Sean Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] tools.trace 0.7.10
HI all, this is a new release of tools.trace that mainly includes a patch from Andy Fingerhut fixing a number of issues (TTRACE-16). A summary of the changes can be found in the change log section of the README. For those who wonder, yes, I am still alive working from a remote rural location in Morocco with a huge 4g pipeline. :) Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JOB] Remote Clojure Dev 2 month quick project 20-40 hours per week
Hi Arturo, this is how I work. Fully remote.B2B. Send me an email at lprefonta...@softaddicts.ca if you want us to discuss further. Thank you, Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.9.0 is now available!
Thank you,
I was not searching strictly for a bug or regression, a malpractice was
also something I wanted to ear about.
The let form generates this in both 1.8 & 1.9. No idea why the defrecord
compiles in 1.8 but that could be related
to the way it is expanded in each version. I don't see the point of going
down further on this path.
I will change the macro code here accordingly.
Luc P.
On Tuesday, 2 January 2018 22:22:18 UTC, Nicola Mometto wrote:
>
> The code that caused this issue is
>
> https://github.com/clojure/clojure/commit/a1c3dafec01ab02fb10d91f98b9ffd3241e860c0?diff=unified#diff-03234b041c0917ec98f2ad9477a0a014R260
>
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fclojure%2Fcommit%2Fa1c3dafec01ab02fb10d91f98b9ffd3241e860c0%3Fdiff%3Dunified%23diff-03234b041c0917ec98f2ad9477a0a014R260&sa=D&sntz=1&usg=AFQjCNHRjVcQGlXG4OrOts7U2jK06kc8ig>
>
> But this is not a bug in the clojure code nor a regression, in fact
> you can reproduce this in any clojure version with the following code:
>
> (defmacro m [] `[~@(keys &env)])
> (defprotocol p (f [_]))
> (deftype t [^int x] p (f [_] (m)))
>
>
> This is happening for the same reason why (let [x (int 1)] (identity
> ^int x)) throws the same error, the fix in your case is to use (map
> #(with-meta % {}) (keys &env))
>
> On Tue, Jan 2, 2018 at 11:03 PM, Luc > wrote:
> > Hi,
> >
> > finally got some time to dig deeper. The minimal code to reproduce this
> has
> > shrunk:
> >
> > (defprotocol Anonymous
> > (start-job! [this]))
> >
> > (defrecord NoopJob []
> > Anonymous
> > (start-job! [this]
> > (yabug.services.logger/environment)))
> >
> > The environment macro was called by log/error but not by the other
> severity
> > level macros.
> > The error macro within a defrecord is the only case where it fails.
> >
> > This is the environment macro definition:
> >
> > (defmacro environment
> > "Expands to code that generates a map of locals: names to values"
> > []
> > (clojure.pprint/pprint (macroexpand `(zipmap '~(keys &env) [~@(keys
> > &env)])))
> > `(zipmap '~(keys &env) [~@(keys &env)]))
> >
> > I added the macroexpand in the macro to get what it expands to in the
> > context of the defrecord
> > at compile time.
> > Outside of the defrecord the compiler does not complain (let, ...)). The
> > protocol by itself does not seem
> > to be a significant factor. I got this at different places under
> different
> > protocols.
> >
> > This is the 1.9 macro expansion outputted at compile time before ending
> up
> > with exception while evaluating
> > the resulting code:
> >
> > (clojure.core/zipmap
> > '(__hash __meta this __hasheq __extmap)
> > [__hash __meta this __hasheq __extmap])
> >
> > This is the 1.8 macroexpansion of this macro which is a bit shorter,
> there's
> > seem to be less context generated by the defrecord macro
> > expansion:
> >
> > (clojure.core/zipmap '(__meta this __extmap) [__meta this __extmap])
> >
> > The expansion of the defrecord context is slightly bigger but nothing
> hits
> > me when I compare both expanded vectors at the end.
> > I am assuming that this the expression that the compiler cannot evaluate
> in
> > 1.9 since it the error originates from the VectorExpr
> > class.
> > Is there anything obvious on with the evaluation of the last vector in
> the
> > 1.9 expansion that would explain this error ?
> > I don't see it.
> >
> > Just to make things more puzzling the expansion literally works in the
> 1.9
> > REPL:
> >
> > => (defrecord NoopJob []
> > impl/GatewayJob
> > (start-job! [this]
> >(clojure.core/zipmap
> > '(__hash __meta this __hasheq __extmap)
> > [__hash __meta this __hasheq __extmap])))
> > yabug.jobs.noop.NoopJob
> >
> > Grr...
> >
> > Will sleep on it and toy with it tomorrow by expanding a bit the test
> cases.
> > It's nearly 22:00 Morocco time here.
> > I need a break and some sleep.
> >
> > Luc P.
> >
> > On Saturday, 30 December 2017 01:00:05 UTC, Alex Miller wrote:
> >>
> >> On Fri, Dec 29, 2017 at 6:17 PM, Luc wrote:
> >>
> >>>
> >>> here it is, I did not get through the compiler source code yet, it
> might
> >
Re: [ANN] Clojure 1.9.0 is now available!
Should have posted this instead, same protocol. (defprotocol Anonymous (start-job! [this])) ;; Clojure 1.8.0 => (defrecord NoopJob [] Anonymous (start-job! [this] (yabug.services.logger/environment))) (clojure.core/zipmap '(__meta this __extmap) [__meta this __extmap]) yabug.jobs.noop.NoopJob On Tuesday, 2 January 2018 22:15:15 UTC, Alex Miller wrote: > > What’s GatewayJob look like? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.9.0 is now available!
Hi, finally got some time to dig deeper. The minimal code to reproduce this has shrunk: (defprotocol Anonymous (start-job! [this])) (defrecord NoopJob [] Anonymous (start-job! [this] (yabug.services.logger/environment))) The environment macro was called by log/error but not by the other severity level macros. The error macro within a defrecord is the only case where it fails. This is the environment macro definition: (defmacro environment "Expands to code that generates a map of locals: names to values" [] (clojure.pprint/pprint (macroexpand `(zipmap '~(keys &env) [~@(keys &env)]))) `(zipmap '~(keys &env) [~@(keys &env)])) I added the macroexpand in the macro to get what it expands to in the context of the defrecord at compile time. Outside of the defrecord the compiler does not complain (let, ...)). The protocol by itself does not seem to be a significant factor. I got this at different places under different protocols. This is the 1.9 macro expansion outputted at compile time before ending up with exception while evaluating the resulting code: (clojure.core/zipmap '(__hash __meta this __hasheq __extmap) [__hash __meta this __hasheq __extmap]) This is the 1.8 macroexpansion of this macro which is a bit shorter, there's seem to be less context generated by the defrecord macro expansion: (clojure.core/zipmap '(__meta this __extmap) [__meta this __extmap]) The expansion of the defrecord context is slightly bigger but nothing hits me when I compare both expanded vectors at the end. I am assuming that this the expression that the compiler cannot evaluate in 1.9 since it the error originates from the VectorExpr class. Is there anything obvious on with the evaluation of the last vector in the 1.9 expansion that would explain this error ? I don't see it. Just to make things more puzzling the expansion literally works in the 1.9 REPL: => (defrecord NoopJob [] impl/GatewayJob (start-job! [this] (clojure.core/zipmap '(__hash __meta this __hasheq __extmap) [__hash __meta this __hasheq __extmap]))) yabug.jobs.noop.NoopJob Grr... Will sleep on it and toy with it tomorrow by expanding a bit the test cases. It's nearly 22:00 Morocco time here. I need a break and some sleep. Luc P. On Saturday, 30 December 2017 01:00:05 UTC, Alex Miller wrote: > > On Fri, Dec 29, 2017 at 6:17 PM, Luc > wrote: > > >> here it is, I did not get through the compiler source code yet, it might >> be obvious to you: >> >> java.lang.UnsupportedOperationException: Can't type hint a primitive >> local, compiling:(yabug/jobs/noop.clj:21:9) >> Exception in thread "main" java.lang.UnsupportedOperationException: Can't >> type hint a primitive local, compiling:(*yabug/jobs/noop.clj:21:9*) >> > > What's the code here? ^^ > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.9.0 is now available!
The call to the log/error macro. Theres an interaction with the expanded code from the defrecord macro and this macro. I posted both expansions in a message 30secs ago. Ill play with these this weekend to see if I can narrow it down further. On Saturday, 30 December 2017 01:00:05 UTC, Alex Miller wrote: > > On Fri, Dec 29, 2017 at 6:17 PM, Luc > wrote: > > >> here it is, I did not get through the compiler source code yet, it might >> be obvious to you: >> >> java.lang.UnsupportedOperationException: Can't type hint a primitive >> local, compiling:(yabug/jobs/noop.clj:21:9) >> Exception in thread "main" java.lang.UnsupportedOperationException: Can't >> type hint a primitive local, compiling:(*yabug/jobs/noop.clj:21:9*) >> > > What's the code here? ^^ > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.9.0 is now available!
I went through the compiler code, it has to do with a bad local binding expression. It crashes in the same way in the REPL with this minimal defrecord: (defrecord NoopJob [name job-controller-channel env job-state parameters job-output] impl/GatewayJob (start-job! [this] (log/error "NoopJob job died unexpectedly !"))) No try catch, no core.async, ... So there's something going on in log/error macro expansion versus the defrecord expansion. I attached two files, the macro expansions of defrecord and the log/error macro. Alex if you prefer I can open a ticket. If nothing obvious comes out that's were it will end up anyway. I'll toy with the combined macro expanded code this weekend to see if I can narrow this a bit more. I have been using the same logging API for years now (since 2009). I really want to know what's broken. I have two dozen projects to upgrade to 1.9 :) It's bizarre at best. Thank you, Luc P. On Saturday, 30 December 2017 00:17:47 UTC, Luc wrote: > > Hi Alex, > > here it is, I did not get through the compiler source code yet, it might > be obvious to you: > > java.lang.UnsupportedOperationException: Can't type hint a primitive > local, compiling:(yabug/jobs/noop.clj:21:9) > Exception in thread "main" java.lang.UnsupportedOperationException: Can't > type hint a primitive local, compiling:(yabug/jobs/noop.clj:21:9) > at clojure.lang.Compiler.analyze(Compiler.java:6792) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$VectorExpr.parse(Compiler.java:3253) > at clojure.lang.Compiler.analyze(Compiler.java:6775) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3881) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7005) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:6991) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3881) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7005) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:6991) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100) > at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2334) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100) > at clojure.lang.Compiler$NewInstanceMethod.parse(Compiler.java:8431) > at clojure.lang.Compiler$NewInstanceExpr.build(Compiler.java:7937) > at > clojure.lang.Compiler$NewInstanceExpr$DeftypeParser.parse(Compiler.java:7813) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100) > at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6420) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100) > at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5460) > at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4022) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7001) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3813) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7005) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6330) > at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003) > at clojure.lang.Compiler.analyze(Compiler.java:6773) > at clojure.lang.Compiler.analyze(Compiler.java:6729) > at clojure.lang.Compiler.compile1(Compiler.java:7604) > at clojure.lang.Compiler.compile(Compiler.java:7676) > at clojure.lang.RT.compile(RT.java:413) > at clojure.lang.RT.load(RT.java:458) > at clojure.lang.RT.load(RT.java:426) > at clojure.core$load$fn__6548.invoke(core.clj:604
Re: [ANN] Clojure 1.9.0 is now available!
Var.applyTo(Var.java:702) at clojure.main.main(main.java:37) Caused by: java.lang.UnsupportedOperationException: Can't type hint a primitive local at clojure.lang.Compiler$LocalBindingExpr.(Compiler.java:5999) at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7183) at clojure.lang.Compiler.analyze(Compiler.java:6752) Will get this up and running this weekend to see if it can be reproduced at runtime and post the result here. I need to revive some setups, it's a project that had been put on ice for a while. Thank you, Happy New Year, Luc On Friday, 29 December 2017 01:02:51 UTC, Alex Miller wrote: > > What’s the full stack trace on the original exception? (Or if same repros > without aot)? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.9.0 is now available!
Hi, I am baffled. I switched a project from 1.8 to 1.9.0 upgrading also other dependencies (latest version fo core.async, ...) via lein ancient. As usual I ran an AOT pass to make sure I don't have anything fishy before running the code. I got this from the AOT pass: java.lang.UnsupportedOperationException: Can't type hint a primitive local Oupse... I Reverted to 1.8 w/o reverting the dependency changes. it AOTed w/o a glitch. I narrowed it at: (:ns ) (defprotocol GatewayJob (start-job! [this] "Start the given job") ...) (:ns ) (defrecord NoopJob [name job-controller-channel env job-state parameters job-output] impl/GatewayJob (start-job! [this] ... (try (catch Exception e# (reset! job-state :failed) (>!! job-controller-channel [this :new-state :failed :error e#]) (log/error (format "NoopJob job died unexpectedly !") e#) ))) <- Here error is a macro which expands here to: (clojure.tools.logging/log* logger__458__auto__ :error nil (clojure.core/print-str "NoopJob job died unexpectedly !")) The (try (catch...) compiles w/o problems outside of the protocol implementation. It bombs a soon as it is embedded in a protocol implementation. 3 instances in three different namespaces same behavior and same code pattern (try .. catch .. reset! >!! ... I have been toying with this for an hour but I need some new direction(s) to eventually nail it. I dived in the list of changes of 1.9 but my search didn't come up with anything relevant yet. Anything changed in the defrecord macro expansion that could explain this ? Something related to core.async ? (it works with 1.8 w/o reverting the other dependencies however) A malpractice in the code structure that was tolerated so far ? I looked at the macro expansion of the defrecord but did not find anything wrong on the surface. Note that I did not yet attempt to run this project from source. That's forthcoming but I would expect it to crash at runtime.. Any idea is welcomed. Thank you, Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure for beginners
Hi, Peruse github and read some code until you can find an anchor point to get you started. You might find some problem/need solved that relates to some of your past experience and allows you to train with ‘real’ code. Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Any data about just how much loc Clojure shaves off java?
At least 7-10 times less code on average. Except for UIs, UIs are naturally bloated code wise 😬 I spend much more time thinking about solving problems and testing than writing code. It was the reverse in other languages. And refactoring is a piece of cake, no need for these heavy tools found in OO. It’s clearly not just a syntax thing. When I train people to take over a system I wrote, they end up with bulging eyes when they realize how much is done in a few lines. I remember recently the look on some faces when I highlighted the 4 lines of code driving some intense CPU processing on a 12 CPUs server... at 95%+ with the help of a couple of transducers and the reducers library.. Like the Visa add, it’s priceless 🤣 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: beginning to learn Clojure after imperative programming my whole life
The other unpleasant option to climb the learning curve asap is to end up with a deadline to spit out a product 😬 I did it, 5 months of pure Hell 😈 After that the pain went away, either my brain adapted or my nervous system could not feel it anymore, can't remember 🤣 Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
HTTPS for dev.clojure.org?
At a minimum, nginx could proxy jira no ? You could force http redirection to https. My 2 cents. Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Nightcoders.net, a cloud IDE for ClojureScript
Works like a charm from my ipad pro 😁 Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AOT classes with clj files on classpath causing ClassNotFoundException
We AOT often dependent projects. We are very careful meeting the exclusions suggestions reported by lein deps :tree. Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
That emacs joke gets my week started with some abdominal pain 😂😂 I support strictness 😬 Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Release 0.34.0 of Counterclockwise
I remember this problem but this is an eclipse bug if my memory is not failing. They had removed Marketplace by mistake. Are you using the latest version of Eclipse ? Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN]: clojure.tools.trace 0.7.9
A Clojure trace tool. Defines tracing macros/fns to help you see what your code is doing. Summary of changes of this release: * Release 0.7.9 October 8, 2015: * Closed TTRACE-11, trace-vars/untrace-vars now accept vars * Closed TTRACE-12, move away from Java 5, extend some new throwables with ThrowableRecompose * Added more tests for TTRACE-12 -- Luc Préfontaine SoftAddicts inc. Québec, Canada Rabat, Morocco -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Lets make it clear (the ironic portion seems to obfuscate my email). I did not criticIzed his work and if you ask me, yes his work is stellar. I fully agreed with him that maintenance is often a less than funny task. Inconsistency in code when maintaining code however is more the norm than the exception even within a single organization. Tension between day to day maintenance pain versus all the other constraints will not disappear tomorrow. Code ages. It takes around 5 years to reach maturity. Afterward you need to prevent decay. This it what I can say after going through so many software projects. I tried to put things in perspective. Real-life constraints exist for business driven projects and open source projects. It seems that you are not interested at all by these. Fine. That's your call. Now if you think that because I did not contribute to patches in Clojure core makes my conclusions about maintenance work unworthy you are erring. And this a very soft statement from my part :) The ironic section was partly about my inadequate skills and you fell happily into this trap. If you really want to discuss my professional achievements send me a private email. This is not the place to discuss this and is orthogonal to the point brought up by Nicola. Which is absolutely valid but hard to solve in a satisfactory way given the constraints. Clojure in Clojure on the JVM and CLR will ease up this... Eventually when some time will have passed. Sent from my iPhone > On Jul 20, 2015, at 10:08, Colin Fleming wrote: > > Leaving aside your usual "humour", you are once again setting up a total > strawman. Nicola did not say that maintenance should be as much fun as > writing new code, nor did he propose rewriting anything. He made a very > specific claim - that contributing to the Clojure codebase is much less > pleasant than it could be, not because the indentation style is unusual but > because it is inconsistent. > > Since he has a long history of writing very high quality patches for Clojure > whereas you, as far as I can tell, have never written any, means that his > opinion holds a lot more weight in this discussion, for me at least. > >> On 20 July 2015 at 14:45, Luc Prefontaine >> wrote: >> >> --- advanced warning: the following section contains a lethal form of irony, >> please skip it if your health condition does not tolerate irony --- >> >> Sure and I never maintained code written by others in 30 years... Never >> wrote patches, never had to comply with odd indentation habits. >> I am an absolute newbie on that subject. >> >> I always write new code and leave maintenance to other less fortunate people. >> >> --- end of ironic section --- >> >> I agree with you. Totally. >> >> Maintenance has never been funnier than new dev and will never be. >> >> Day to day maintenance specifically is a pain in the ass. >> >> Preemptive rewrites as part of maintenance is doable when the code reaches >> an unbearable state >> but someone in charge has to call the shots. >> >> I had numerous discussions about rewriting in the last few decades and yes >> patch consistency is always brought forward. >> >> The driving factors around a decision like this are: the life expectancy of >> the code vs it's complexity vs maintenance cost and agility vs risks >> involved in a rewrite vs budget vs accumulated knowledge. >> >> The maintainer's pain is not the only factor taken into account and often >> not the most important. >> >> That's the harsh reality of life. >> >> Ideally we would always write new stuff and trash code every 2/3 years to >> keep our mood at its peak. >> >> Life is not like that. Sorry :) >> >> Sent from my iPhone >> >> > On Jul 20, 2015, at 08:14, Nicola Mometto wrote: >> > >> > I take it you have never worked on a patch for clojure. >> > I have, and I can tell you that it's not the indentation style the >> > issue -- everybody likes his own and it's definitely in the >> > maintainer's rights to chose what indentation style should be used and >> > for contributors to adapt, I don't have a problem with that. >> > I have a problem with the fact that the indentation style is not >> > consistent even between lines of the same method, tabs and spaces are >> > mixed everywhere -- for every non trivial patch I submit I have to >> > spend non trivial amounts of time to reindent my code using spaces or >> > tabs where appropriate to be consistent with the surrounding code and >> > making sure I
Re: #{:rant} Questions about contribution policy and clojure compiler source.
--- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone > On Jul 20, 2015, at 08:14, Nicola Mometto wrote: > > I take it you have never worked on a patch for clojure. > I have, and I can tell you that it's not the indentation style the > issue -- everybody likes his own and it's definitely in the > maintainer's rights to chose what indentation style should be used and > for contributors to adapt, I don't have a problem with that. > I have a problem with the fact that the indentation style is not > consistent even between lines of the same method, tabs and spaces are > mixed everywhere -- for every non trivial patch I submit I have to > spend non trivial amounts of time to reindent my code using spaces or > tabs where appropriate to be consistent with the surrounding code and > making sure I don't accidentally commit whitespace changes in my > patches. > It's certainly not the biggest issue (not even close to it) in the > contributing process, but it definitely is an issue and it doesn't > help making the overall contributing experience a pleasant one, or one > would want to repeat. > > And the claim that no indentation fix can happen to avoid breaking > existing patches in jira is frankly laughable. With the amount of time > that usually passes between the writing of a patch and its application > to the code base, a lot of them already need to be rebased/rewritten > to apply cleanly, often multiple times. > > On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine > wrote: >> Sure, indentation is what gets the code running on metal :)) >> >> Not ranting here, just my abs dying from the pain as I laugh :)) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad > On Jul 19, 2015, at 09:36, Colin Fleming wrote: > >> On 18 July 2015 at 19:54, Luc Préfontaine >> wrote: >> My tone does not please you ? It could be worse and I reserve my right to >> free speech. Have a look at some Linus rants. I am far from that level. > > I think everyone in this community should aspire to more than "I'm not as > rude as Linus". > >> There's nothing that makes me shiver more than political correctness. > > Political correctness has nothing to do with remaining civil in a discussion. > > >>> On Jul 18, 2015, at 13:32, Andrey Antukh wrote: >>> >>> >>> >>>> On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine >>>> wrote: >>>> Aaah ! The pull request looms again :) >>>> >>>> A bug tracking system is essentialy to coordinate efforts, pull request >>>> are not a mechanism to track fixes/improvements and discuss about >>>> them. That may work for a very small team. The # of clojure contributors >>>> far excess that size. >>> >>> >>> >>>> >>>> Pull requests/gitbhub issues are used by Clojure library maintainers >>>> outside of the core, >>>> their respective contributor team size makes this usable. >>>> >>>> Choosing one tracking system is a feat by itself, Jira does everything >>>> albeit it may be a beast to configure. >>>> I think that the choice of Jira predates moving the Clojure code from >>>> google to github but I may be wrong. >>>> The github tracking system was not at par with Jira features at that time >>>> anyway. >>>> >>>> Once that choice is done, moving out to something else requires a >>>> significant effort, you need to pull all this history you built about >>>> your software into your new bug tracking solution. You can't loose this, >>>> it's your software collective memory. >>>> >>>> All this discussion around pull request IMO is more an expression of human >>>> lazyness. Having to document is always seen as a >>>> chore by most developpers. This is not an arcane human trait, it has been >>>> known for decades. >>>> >>>> Anything else requires a discussion forum if you want to maintain a >>>> minimal level of quality and allow some discussions around the issue being >>>> fixed >>>> in a large team effort/critical piece of software. A mailing list is not >>>> at par with a bug tracking system in this regard. >>>> >>>> Curiously, linux has a bug tracking system and people submit patches or >>>> links are made to patches. >>>> Take a walk on launchpad. >>>> >>>> No serious software business would drive their dev without a tracking >>>> system. Open source projects are no >>>> different if they want to attain some level of success. If critical open >>>> source is to be used by businesses, it has to >>>> play with similar tools. Clojure too me is critical to my business and to >>>> many others. It cannot fail on us. >>>> It would be like building pyramids on moving sand. >>>> >>>> Again there's no Kumbaya song playing here. >>>> >>>> As a last note, Alex Miller must dream about the emails exchanged on the >>>> mailing list. >>>> Suggestions are certainly looked upon and discussed upstream. It does not >&
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I agree with you but changes like this need time to bloom and are motivated by increased pressure to release. We have been seeing more of that in the last year. Linus did not find solid maintainers day one. You need to test drive individuals before you can delegate significant chunks and not worry about the minute details and just review work at the end of the pipeline. By now such people should be identified in the community. It's kind of an internal Cognitec subject but some public statement looks to me inevitable :) Alex ? Sent from my iPhone > On Jul 19, 2015, at 02:21, Mikera wrote: > >> On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote: >> I don't think the tweets you link are the 'normal approach'. I would call >> them pretty unusual in several aspects. For one, I think that for the vast >> majority of Clojure tickets created, no on asks and gets Rich's comments on >> them before they are created. Second, most end up being committed as the >> submitter created them, with fewer rounds of review and updates. Most of >> them are a lot less work on the part of the contributor than the two >> examples mentioned. >> >> Note: I am not saying that those two examples didn't happen, or that there >> are no others like that. I am saying they are unusual examples, as compared >> to the great majority of Clojure tickets. Most tickets that have a change >> committed for them end up being committed as a patch submitted by a >> contributor, without being implemented differently. >> >> It is fairly common for there to be months or years of waiting time for a >> ticket to be considered. Rich is one person, and like most people, he gets >> to choose how much time he spends on volunteer projects, and what projects >> those are. Alex Miller spends a significant fraction of his time tending to >> tickets and commenting on and reviewing patches. > > This point (i.e. lead time) is by far my biggest gripe about the Clojure > contribution process. It causes a number of problems: > A) Contributors get de-motivated waiting for feedback / communication > B) Patches often become stale. This wastes more time > C) People forget what they were thinking about months or years ago > D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is a > good example) > E) It creates the perception (even if it is not the reality?) that Clojure is > unfriendly to contributors > > My practical suggestion is simple: Clojure needs more "trusted maintainers" > who know particular parts of Clojure well and can work more closely with > contributors to get patches in a good state for Rich to review, and > potentially even merge the simpler types of changes (bug fixes, documentation > updates, basic refactoring, indentation etc.). Rich's time can then be spent > on the high value stuff (reviewing good quality patches only when they are > ready in the view of the "trusted maintainer", considering changes which > impact language design etc.). > > FWIW It's worth comparing the rate of development on Clojure vs. Linux: > > Clojure: https://github.com/clojure/clojure/graphs/commit-activity (<10 > commits per week) > Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 > commits per week) > > Obviously Linux is a bigger project, but there is still only one BDFL in both > cases (and I am sure both BDFLs are very busy!) > > So how does Linus do it? The answer is organisation. Linux has many trusted > subsystem maintainers who do most of the work reviewing and merging patches. > Linus may have the final say on everything but the Linux community has done a > lot of thinking and self-organisation to make sure that Linus is not usually > the bottleneck. > > Also worth noting that Linus does indeed use pull requests (just not GitHub > ones, see the extended discussion here if interested: > https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not saying > Rich has to do so himself, but the "trusted maintainers" would be able to do > so if it helped with the workflow for work-in-progress patches. > > >> >> As for indentation of Java code, it is called Whitesmiths style: >> https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style >> >> Clojure was the first project I came across using this indentation style, >> but Rich isn't the only one to use it. A few bits of code have crept in >> over the years using other indentation styles, usually contributed by others. >> >> Andy >> >>> On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh wrote: >>> Hi! >>> >>> I have some, maybe controversial, questions... >>> >>> A little bit of context: >>> https://twitter.com/aphyr/status/621806683908542464 >>> >>> Why this is like a normal approach for managing third party contributions >>> to clojure core? This kind of things the only discourages the >>> contributions. Maybe I don't have more context about this concrete case, >>> but seems is
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Your comments are one-sided. When I modify code written by others, I follow their style. I do not complain about their code formatting habits. I wrote/modified enough code in 30 years written by hundreds of individuals to find emphasis on code formatting and variable naming a waste of time and effort. If the code structure is good essentially it's maintainable. I answered a recurring subject of low-level importance wrapped in some humorous wording to try to pass under the political correctness radar that will eventually kill humanity. It does not please you ? Let the OP comment on this, it was not addressed to you personally. Just zap. He can rant on me on this mailing list, I will not whine about it. I'm made though. Kumbaya... Sent from my iPhone > On Jul 19, 2015, at 04:21, Max Gonzih wrote: > > > >> On Saturday, July 18, 2015 at 5:44:29 PM UTC+2, Luc wrote: >> Sure, indentation is what gets the code running on metal :)) >> >> Not ranting here, just my abs dying from the pain as I laugh :)) > > Comments like that are often linked as an expample of "Functional > Programmers" attitude. > Let's not do that. > > I beleive that talking things out is the only way to improve in cases like > that. > But it can be only achieved through civil and equal discussion without any > attempts to undermine authority of each other. > > Let's try to do that, I beleive people in the clojure community can do that > easily. > > Thanks! > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov wrote: > On 18 July 2015 at 22:52, Luc Préfontaine > wrote: > > > Each linux kernel release involves hundreds of people. > > Many release had above a thousand contributors. > > This is for your enlightenment and are old figures: > > > > http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ > > > > Did you even read this article? "75% – The share of all kernel > development that is done by developers who are being paid for their > work." This doesn't exactly contract what I said. > > > > > > There are as many people not officially hired to work for linux > > operating system > > focused businesses that submit patches through the ticketing system. > > > > As for the development lifecycle of the linux kernel: > > http://www.linuxfoundation.org/content/22-lifecycle-patch > > > > You can read the other sections, if you find the Clojure dev. > > lifecycle arcane, you will > > freak at this one. > > Obviously, these guys must all be old fashion outdated folks in > > this era of instant > > communication and snapchat like media, there's no other explanation > > for such a > > bureaucratic process :) > > > > How much pain is it to upgrade to a new Clojure version ? Nil. > > How much pain is it to upgrade to a new linux kernel ? > > Not nil but considering the size of this project, its ramifications > > and the hardware > > changing every 6 months, not big. On par with Clojure I would say. > > > > How much pain to upgrade to a new version of Ruby on Rails ? > > Huge. I know, I have been through this a number of times. Not just > > major releases, even maintenance ones are a nightmare to upgrade. > > > > Disclaimer: I am not saying that Rails has a bad lifecycle, I am > > just stating feedback > > from me and other people that actually lived this. Gee, I sound like > > Mallard Fillmore... > > > > That's for the political correctness of this post. And to avoid > > being harassed, sued, whatever. > > > > I would like us to compare carrots with carrots, not with apples or > > strawberries but if > > you insist > > > > To me the result is utterly important. > > We deliver 24/7 software under linux using Clojure. We have up > > times of more than 300 days. One upgrade a year. This is the world > > that live into. > > > > Making it 'harder to contribute' like you state is the price to pay > > for some form of > > quality control. Contributing to something that eventually crumbles > > because of a > > lack of QA is of no value. To us all. > > > > Stuart has made this evaluation. Since it models by some aspect how > > a successful > > project like Linux is managed, I find it hard to throw a stone at > > the current lifecycle. > > > > That may look to you as an ultra-conservative approach. Let's put > > it this way, > > I would use Linux and Clojure to control a nuclear plant anytime. > > > > I am quite certain sure I would not use Rails or Ruby for this > > purpose. > > > > As this conversation isn't really going anywhere I'll keep my > thoughts to myself. > > > > > > Luc P. > > > > > > Luc P. > > > > Sent from my iPad > > > > On Jul 18, 2015, at 14:32, Bozhidar Batsov > > wrote: > > > > On 18 July 2015 at 20:18, Luc Prefontaine > > wrote: > > > >> Aaah ! The pull request looms again :) > >> > >> A bug tracking system is essentialy to coordinate efforts, pull > >> request are not a mechanism to track fixes/improvements and > >> discuss about them. That may work for a very small team. The # of > >> clojure contributors far excess that size. > >> > > > > So, Ruby on Rails is a small project, right? And if we have many > > contributors we should show no respect for their time - we should > >
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. Luc P. Luc P. Sent from my iPad > On Jul 18, 2015, at 14:32, Bozhidar Batsov wrote: > >> On 18 July 2015 at 20:18, Luc Prefontaine >> wrote: >> Aaah ! The pull request looms again :) >> >> A bug tracking system is essentialy to coordinate efforts, pull request are >> not a mechanism to track fixes/improvements and discuss about >> them. That may work for a very small team. The # of clojure contributors far >> excess that size. > > So, Ruby on Rails is a small project, right? And if we have many contributors > we should show no respect for their time - we should actually make it harder > to contribute, so it'd be easier on us, right? > >> >> Pull requests/gitbhub issues are used by Clojure library maintainers outside >> of the core, >> their respective contributor team size makes this usable. >> >> Choosing one tracking system is a feat by itself, Jira does everything >> albeit it may be a beast to configure. >> I think that the choice of Jira predates moving the Clojure code from google >> to github but I may be wrong. >> The github tracking system was not at par with Jira features at that time >> anyway. > > Many projects predate GitHub, yet they eventually adopted it. And it's never > about GitHub in particular - it's only about making things efficient and > pleasant for everyone involved. I work with JIRA for a living and my team > mostly hates it, I can only imagine the willingness of casual contributors to > deal with it. How do you do an inline patch review in JIRA? How do you update > patches automatically? It's never about particular tools, it's all about > making smart choices. > >> >> Once that choice is done, moving out to something else requires a >> significant effort, you need to pull all this history you built about >> your software into your new bug tracking solution. You can't loose this, >> it's your software collective memory. >> >> All this discussion around pull request IMO is more an expression of human >> lazyness. Having to document is always seen as a >> chore by most developpers. This is not an arcane human trait, it has been >> known for decades. > > Laziness? Time is our most important resource and we should always be mindful > of the time people have to invest (waste)
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Excuse-me if I hurt your personal feelings but most of the proponents of pull requests so far have been in fact extremely allergic to report problems/improvements in Jira first before submitting a code change. I was addressing this audience because this subject comes back over and over again. My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I restrain myself as much as I can :) Believe me. There's nothing that makes me shiver more than political correctness. Now back to real issues: a) If you have a ticket in Jira and no patch attached to it, how do you link that with your code base ? How can you avoid issuing a patch ? How can a reviewer figure out exactly the scope of your changes if they are no patches attached to it ? b) You can propose improvements through Jira plus the mailing list. What would be a better alternative ? c) How do you preserve history of changes and code mutations throughout this process ? These are practical workflow issues. If you can shed some light on this and suggest an improved workflow, there are people listening. There's no free lunch but many people would like one. To me it boils down to this question: Can the needs of one person compromise a group effort ? I don't think so. But this is only my opinion. Luc P. Sent from my iPad > On Jul 18, 2015, at 13:32, Andrey Antukh wrote: > > > >> On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine >> wrote: >> Aaah ! The pull request looms again :) >> >> A bug tracking system is essentialy to coordinate efforts, pull request are >> not a mechanism to track fixes/improvements and discuss about >> them. That may work for a very small team. The # of clojure contributors far >> excess that size. > > > >> >> Pull requests/gitbhub issues are used by Clojure library maintainers outside >> of the core, >> their respective contributor team size makes this usable. >> >> Choosing one tracking system is a feat by itself, Jira does everything >> albeit it may be a beast to configure. >> I think that the choice of Jira predates moving the Clojure code from google >> to github but I may be wrong. >> The github tracking system was not at par with Jira features at that time >> anyway. >> >> Once that choice is done, moving out to something else requires a >> significant effort, you need to pull all this history you built about >> your software into your new bug tracking solution. You can't loose this, >> it's your software collective memory. >> >> All this discussion around pull request IMO is more an expression of human >> lazyness. Having to document is always seen as a >> chore by most developpers. This is not an arcane human trait, it has been >> known for decades. >> >> Anything else requires a discussion forum if you want to maintain a minimal >> level of quality and allow some discussions around the issue being fixed >> in a large team effort/critical piece of software. A mailing list is not at >> par with a bug tracking system in this regard. >> >> Curiously, linux has a bug tracking system and people submit patches or >> links are made to patches. >> Take a walk on launchpad. >> >> No serious software business would drive their dev without a tracking >> system. Open source projects are no >> different if they want to attain some level of success. If critical open >> source is to be used by businesses, it has to >> play with similar tools. Clojure too me is critical to my business and to >> many others. It cannot fail on us. >> It would be like building pyramids on moving sand. >> >> Again there's no Kumbaya song playing here. >> >> As a last note, Alex Miller must dream about the emails exchanged on the >> mailing list. >> Suggestions are certainly looked upon and discussed upstream. It does not >> mean that they will be considered >> worth to investigate/implement or they may come out differently (that ego >> thing looming again). >> >> +1 for Jira and patches. > > The django community works with both tools. Pull request are just for code > review and patch attachment mechanism, and bug tracking system for coordinate > the efforts. Both them are not incompatible. > And django core team is not precisely small. > > The Pull-Request is not about laziness, is about eliminate friction. And > allow better and more human friendly code review > process. > > I'm only try improve the contribution process and IMHO your tone is a little > bit out of pla
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh wrote: > On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates > wrote: > > > +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since > > when did software design by committee work; anyone remember J2EE? > > (and yes, that does deserve my mocking tone). > > > > I have no idea about the details being discussed here/why people’s > > noses are out of joint, but I can think of as many success with a > > single overlord in place as there are failures caused by political > > infighting. > > > > In general, I'm pretty happy with the "benevolent dictator" approach. > But some openness would be awesome. As first think that comes in my > mind is: have a clear roadmap for Clojure and its core libraries such > as core.async. > > Some channel for requesting features, and the ability to know a > opinion of the clojure core team about the possibility of the > inclusion of some requested feature. > > Also would be awesome have more painless contribution process. I'm ok > for signing CA, but using patches instead of something like pull > requests (with or without additional review tool) is very arcane and > uncomfortable process. > > I don't suggest to change to something similar to "design by > committee". I only suggest that make some facilities for contribute > may attract more interesting people. And will make more happy > excellent contributors like Zach Tellman or Aphyr. > > I think that things like this are not very complicated to adopt and > has a lot of benefit. > > My two cents! > > > > > On 18 Jul 2015, at 16:44, Luc Prefontaine > > wrote: > > > > Sure, indentation is what gets the code running on metal :)) > > > > Not ranting here, just my abs dying from the pain as I laugh :)) > > > > As for the contrib process, go have a look at Linux. You'll be > > happy that Rich is cool by every meaning of the word. > > > > There's this misconception about open source that we should all wear > > flower collars and sing Kumbaya. Mostly a 60's view of human > > collaboration. > > > > That ain't the way to get it done. > > It works for ants and termites, they work as groups but we are human > > beings with our strong individuality. > > > > Some form of central control is needed. Opposed by traction from > > some i
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone > On Jul 18, 2015, at 07:13, Andrey Antukh wrote: > > Hi! > > I have some, maybe controversial, questions... > > A little bit of context: https://twitter.com/aphyr/status/621806683908542464 > > Why this is like a normal approach for managing third party contributions to > clojure core? This kind of things the only discourages the contributions. > Maybe I don't have more context about this concrete case, but seems is not a > unique. > And in general, I have the perception that the clojure development process is > a little bit opaque... > > An other question: Why the great amount of clojure compiler code has no > indentation style and bunch of commented code. > > It is indented like a freshman. Sorry, I don't want offend any one, but eyes > hurt when reading the code compiler clojure (obviously I'm speaking about the > look and feel, and no the quality of the code). > > Some examples: > > Indentation (or maybe no indentation): > https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 > > Bunch of commented code and also no indentation: > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 > > If you compare some clojure compiler code with different code snippets from > other languages, the indentation is clearly more cared: > > Kotlin: > https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 > Rust: > https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 > Ceylon: > https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 > > This is a random list of code snippets from different compilers with > indentation that is more human friendly. > > I don't intend judge any one, but when a I learn Clojure compiler I expect > something different. I expect something more carefully done. > > No body thinks the same thing that me? > > I think that have a sane, more open contribution policy, with clear and more > cared code formatting, is not very complicated thing and is going to favor > the clojure and its community. > > Andrey > -- > Andrey Antukh - Андрей Антух - > http://www.niwi.nz > https://github.com/niwinz > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To
Re: clojure don't support .clj source code file by utf-8.
I agree that the number of encodings makes a full proof transparent solution impossible to implement. I still think that some simpler text file handling out of the box should exist on the JVM to read utf files. Utf-8 is kind of natural within the JVM. Exposing all this BOM machinery every time you need to read a text file is a pain. Either implement BOM recognition on the fly or make it mandatory in utf-8 files every where. The BOM is required for utf-16 and above as far as I know. The time spent on stupid issues like this one must be significant given the number of people struggling with this... Sent from my iPhone > On Jul 13, 2015, at 18:46, Sungjin Chun wrote: > > Assume that charset is the same, even this case, there're many types of > encoding scheme for it and for portability, > you have to consider both input and output encoding. On Mac OS X or Linux, > this is controlled by locale system, > on windows 1. you can force encoding system using control panel or you have > to change your encoding before > output to console. Here, we in korea, do this stuffs for internationalized > application development. Of course, you have > to use correct charset for i18n application :-) > >> On Mon, Jul 13, 2015 at 11:56 PM Luc Préfontaine >> wrote: >> I cannot remember the details but in 2010 I had similar problem in a >> cross-platform project >> using Clojure. And problems earlier in another cross-platform/cross-language >> project. >> >> So it's the reverse way, no BOM at all... >> >> Can't believe we are in 2015 still struggling with character set issues. >> Having to to think about this when saving a file in notepad...That's >> depressing. >> No wonder why I now stay away from Windows as much as possible. >> >> I can't understand why we cannot get some transparent behavior from the Java >> runtime. >> These are human readable text files. Not some unreadable binary format. >> Googled a bit about this and numerous people face this problem reading >> windows generated >> files. They all ended up having to skip the BOM if present when reading the >> file. >> >> So much for portability. Beurk. >> >> > On Mon, Jul 13, 2015 at 2:52 PM, Luc Préfontaine < >> > lprefonta...@softaddicts.ca> wrote: >> > >> > > BG is right on it. I hit this problem a decade ago (roughly :)). >> > > UTF-8 files with no BOM are not handled properly on windows. >> > > It assumes that they are ASCII coded. That works partially (both >> > > character >> > > sets have the same >> > > encoding for many characters) but eventually fails. >> > > >> > >> > > Make sure that the files have a BOM. You can do this on a per file basis >> > > using an IDE >> > > (Eclipse, ...) or if you can use bash scripts to do this if you have >> > > access to a u*x environment. >> > > I did not find an equivalent native windows tool but they might be some >> > > to >> > > do this in batch. >> > > >> > > Luc P. >> > > >> > >> > Clojure source files are expected to be in UTF-8 and Clojure on Windows >> > doesn't require a BOM. >> > >> > In fact, Clojure files must not contain a BOM because it isn't considered >> > to be whitespace by the clojure parser and will cause the error "Unable to >> > resolve symbol: ? in this context". >> > >> > Some software, such as Windows notepad uses the presence of a BOM to detect >> > UTF-8, but that can be overridden in the File | Open dialog. Other than >> > that, the behaviour of the BOM on Clojure between Linux and Windows should >> > be the same - this stuff is all handled by Java code in the JDK - not by >> > the Windows platform. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clojure@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> > your first post. >> > To unsubscribe from this group, send email to >> > clojure+unsubscr...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> > --- >> > You received this message because you are subscribed to the Google Groups >> > "Clojure" group. >> > To unsubscribe from this group and stop receiving emails from it
Re: clojure don't support .clj source code file by utf-8.
I cannot remember the details but in 2010 I had similar problem in a cross-platform project using Clojure. And problems earlier in another cross-platform/cross-language project. So it's the reverse way, no BOM at all... Can't believe we are in 2015 still struggling with character set issues. Having to to think about this when saving a file in notepad...That's depressing. No wonder why I now stay away from Windows as much as possible. I can't understand why we cannot get some transparent behavior from the Java runtime. These are human readable text files. Not some unreadable binary format. Googled a bit about this and numerous people face this problem reading windows generated files. They all ended up having to skip the BOM if present when reading the file. So much for portability. Beurk. > On Mon, Jul 13, 2015 at 2:52 PM, Luc Préfontaine < > lprefonta...@softaddicts.ca> wrote: > > > BG is right on it. I hit this problem a decade ago (roughly :)). > > UTF-8 files with no BOM are not handled properly on windows. > > It assumes that they are ASCII coded. That works partially (both character > > sets have the same > > encoding for many characters) but eventually fails. > > > > > Make sure that the files have a BOM. You can do this on a per file basis > > using an IDE > > (Eclipse, ...) or if you can use bash scripts to do this if you have > > access to a u*x environment. > > I did not find an equivalent native windows tool but they might be some to > > do this in batch. > > > > Luc P. > > > > Clojure source files are expected to be in UTF-8 and Clojure on Windows > doesn't require a BOM. > > In fact, Clojure files must not contain a BOM because it isn't considered > to be whitespace by the clojure parser and will cause the error "Unable to > resolve symbol: ? in this context". > > Some software, such as Windows notepad uses the presence of a BOM to detect > UTF-8, but that can be overridden in the File | Open dialog. Other than > that, the behaviour of the BOM on Clojure between Linux and Windows should > be the same - this stuff is all handled by Java code in the JDK - not by > the Windows platform. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure don't support .clj source code file by utf-8.
BG is right on it. I hit this problem a decade ago (roughly :)). UTF-8 files with no BOM are not handled properly on windows. It assumes that they are ASCII coded. That works partially (both character sets have the same encoding for many characters) but eventually fails. Make sure that the files have a BOM. You can do this on a per file basis using an IDE (Eclipse, ...) or if you can use bash scripts to do this if you have access to a u*x environment. I did not find an equivalent native windows tool but they might be some to do this in batch. Luc P. > Of course not. My files do not have BOM. So the problem lies in the > BOM thingy? > > On Mon, Jul 13, 2015 at 10:07 AM Baishampayan Ghose > wrote: > > > Hi, > > > > IIRC Windows requires UTF-8 encoded files to have the BOM (Byte Order > > Mark). > > Can you verify that your file has the BOM? > > > > Regards, > > BG > > > > On Thu, Jul 9, 2015 at 8:03 AM, Alex Woods wrote: > > > clojure don't support .clj source code file by utf-8. > > > it's ok when the .clj source code files by ascii > > > > > > env: > > > windows7,jdk1.8u45,lein2.5.0 > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > your > > > first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > > --- > > > You received this message because you are subscribed to the Google Groups > > > "Clojure" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to clojure+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > -- > > Baishampayan Ghose > > b.ghose at gmail.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 > > --- > > You received this message because you are subscribed to a topic in the > > Google Groups "Clojure" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/clojure/Rk5JGhq-IJY/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure don't support .clj source code file by utf-8.
Windows a problem ? N, impossible :))) Luc P. Sent from my iPhone > On Jul 12, 2015, at 19:39, Sungjin Chun wrote: > > On Mac OS X (Yosemite) and Linux (Ubuntu), this code works well (I'm using > en_US.UTF-8 as > charset and encoding for my system). > > I suspect that the OS (Windows) or its configuration is the source of the > problem. > >> On Sunday, July 12, 2015 at 10:57:59 AM UTC+9, Denis Fuenzalida wrote: >> I was able to reproduce an error involving Windows 7 and UTF-8 in a virtual >> machine with VirtualBox 4.3 (not sure if it is the issue that Alex >> experienced though): >> >> * Installed Windows 7, then used Ninite.com to install Notepad++ (text >> editor), Oracle JDK 8 (1.8.0_45). Installed Leiningen 2.5.1 as .bat file >> from the website. >> * Created a new leiningen project with "lein new app utf8test" >> * Opened the file src/utf8test/core.clj in Notepad++ and replaced the >> contents of with the following: >> >> (ns utf8test.core (:gen-class)) >> (defn saludo-año [año] (str "Saludos en el año " año)) >> (def saludo-japonés "どうもありがとう") >> (defn -main [& args] >> (println (saludo-año 2015)) >> (println saludo-japonés)) >> >> * On Notepad++ went to the Encoding menu and selected "Encoding in UTF-8 w/o >> BOM". Saved the file. When running "lein run" on the cmd.exe console it >> works but it outputs garbage instead of any non-ascii character (see >> http://i.imgur.com/H0rngyq.png) >> >> * To trigger the compilation error, change the encoding of the file in >> Notepad++ to "Encoding in UTF-8". Save the file. When running "lein run" >> this time it will not compile and complains about being unable to resolve a >> symbol (see http://i.imgur.com/3SHegTH.png) ... however, if you type the >> contents of the file in the cmd.exe console (with "type >> src\utf8test\core.clj") you'll see there's some extra garbage chars before >> the namespace declaration. >> >> My theory is that such garbage chars are the Byte Order Mark (BOM) Unicode >> character (https://en.wikipedia.org/wiki/Byte_order_mark) and they are not >> being correctly handled in Windows somewhere in the stack. >> >> I don't use Windows regularly and I never had UTF-8 issues on Linux though. >> >> -- >> >> Denis Fuenzalida >> >> >> El jueves, 9 de julio de 2015, 12:33:46 (UTC-7), Daniel Compton escribió: >>> >>> Hi Alex >>> >>> You'll need to give us some more information about this to help us >>> troubleshoot what's going on. Can you share the file with us? >>>> On Fri, 10 Jul 2015 at 3:59 AM Alex Woods wrote: >>>> clojure don't support .clj source code file by utf-8. >>>> it's ok when the .clj source code files by ascii >>>> >>>> env: >>>> windows7,jdk1.8u45,lein2.5.0 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@googlegroups.com >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+u...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> --- >>>> You received this message because you are subscribed to the Google Groups >>>> "Clojure" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to clojure+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> -- >>> Daniel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Counterclockwise's Plugin Shortcuts for OS X
Create an external tool command (lein eastwood) perhaps ? Sorry, could not resist :) Luc P. Sent from my iPad > On Jul 7, 2015, at 15:21, JPatrick Davenport wrote: > > Hello, > I want to use the linter within Eclipse. I followed the instructions for both > the plugin manager as well as the linter. Unfortunately I don't know the > shortcut keys to run them with Eclipse in OS X. I can't find any menu options > to activate these. Perhaps I'm overlooking something. > > What should I do? > > Thanks, > JPD > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Running test.check and cljs.test tests under Clojurescript
Dunno if this can help you: https://github.com/lprefontaine/clara-rules/blob/master/project.clj I run tests with : lein cljsbuild test-cljs If I my memory is not fooling me. There might be a better way but this is what I had time to tweak this weekend. You need to setup phantomjs, etc...look at the phantomjs folder in the project. Luc P. Sent from my iPhone > On Jul 1, 2015, at 00:03, Nathan Marz wrote: > > I figured out a way to do it by manually launching a ClojureScript REPL, > writing a test runner script, and then invoking that script at the REPL, like > so: https://github.com/nathanmarz/specter/blob/cljs/DEVELOPER.md > > Still wondering if there's a more straightforward way to do this. > > >> On Tuesday, June 30, 2015 at 7:20:58 PM UTC-4, Nathan Marz wrote: >> I'm trying to get Specter's tests running under ClojureScript. I can run the >> tests manually in a REPL just fine, but I cannot figure out a >> straightforward way to run all the tests like you can in Clojure with "lein >> test". >> >> Here are the tests I'm trying to run, which are a mix of tests defined using >> test.check and cljs.test: >> https://github.com/nathanmarz/specter/blob/cljs/test/com/rpl/specter/core_test.cljc >> >> I've tried the instructions in >> http://abratukhin.blogspot.com/2015/03/how-to-set-up-unit-tests-in.html but >> the cemerick.cljs.test package does not seem to run test.check tests defined >> with defspec. >> >> How can I set up a runner to run my tests with a one line command at the >> terminal? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: let vs. let*
I had to query it myself not knowing what this site was all about, nice tutorial, I think I understood it :) Luc P. > raould, > > I find lmgtfy links to be a condescending way to answer a question and I > would prefer that we not use them on this list. If you have an answer or a > link to one, then respond with this, otherwise I do not see a reason to > post this. > > Thanks, > Alex > > > On Thursday, June 18, 2015 at 3:35:53 PM UTC-5, raould wrote: > > > > http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22 > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.7.0b2, lein, cljc and tests
I encountered a couple of glitches around cljc support through figwheel. Updating a .cljc file was triggering a recompilation in some circumstances. I did not investigate further, it kind of disappeared from my horizon but I do not why exactly. Can't relate this to a change in my project yet. Luc P. > Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, > just not if I do ‘lein test’. Is this expected? I am running 2.5.1 > > > On 19 Jun 2015, at 14:46, Gary Trakhman wrote: > > > > Leiningen needs to support cljc, right now only the compiler does, and > > clojure-maven-plugin since a few days ago. > > > > https://github.com/technomancy/leiningen/issues/1827 > > <https://github.com/technomancy/leiningen/issues/1827> > > > > On Fri, Jun 19, 2015 at 9:41 AM Colin Yates > <mailto:colin.ya...@gmail.com>> wrote: > > First - cljc is (for me) a huge upgrade over cljx, which was a great > > solution. Not having to run lein clix auto every time I do a clean is far > > more useful than I realised. > > > > The problem I am having is that cljc test files don't seem to be picked up. > > I have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" > > "test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I > > do a 'lein test some-namespace-in-cljc' then the tests are run. > > > > Has anyone else experienced this and if so, any pointers on moving forward? > > > > 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 > > <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%2bunsubscr...@googlegroups.com> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > <http://groups.google.com/group/clojure?hl=en> > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com > > <mailto:clojure+unsubscr...@googlegroups.com>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > <http://groups.google.com/group/clojure?hl=en> > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com > > <mailto:clojure+unsubscr...@googlegroups.com>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: boot(2) question
Btwy, For is not a loop as in imperative languages. It returns a lazy sequence. Luc P. Sent from my iPhone > On Jun 18, 2015, at 07:51, Haim Ashkenazi wrote: > > Hi, > > I'm trying boot scripting capabilities so I have the following file: > > #!/usr/bin/env boot > (set-env! > :dependencies '[[org.clojure/clojure "1.6.0"]]) > > (defn -main > [] > (println "before") > (for [s ["one" "two" "three"]] > (do > (spit "output" s :append true) > (println s))) > (println "after")) > > > When running this script form the command line all the stuff inside the for > loop is doesn't seem to run: > > ✓ src ➤ ./testboot > before > after > > ... and there's no "out[put" file. Inside a REPL it runs without a problem. > Am I missing something? > > Thanks in advance > > -- > Haim > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: boot(2) question
For is lazy. Replace it with doseq. Use doseq when you want side effects to occur and do not need a result. Luc P. Sent from my iPhone > On Jun 18, 2015, at 07:51, Haim Ashkenazi wrote: > > Hi, > > I'm trying boot scripting capabilities so I have the following file: > > #!/usr/bin/env boot > (set-env! > :dependencies '[[org.clojure/clojure "1.6.0"]]) > > (defn -main > [] > (println "before") > (for [s ["one" "two" "three"]] > (do > (spit "output" s :append true) > (println s))) > (println "after")) > > > When running this script form the command line all the stuff inside the for > loop is doesn't seem to run: > > ✓ src ➤ ./testboot > before > after > > ... and there's no "out[put" file. Inside a REPL it runs without a problem. > Am I missing something? > > Thanks in advance > > -- > Haim > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Time-Bombed Open License - thoughts?
I agree. I can't see how you can build a business model out of this. We already lower the cost for our customers by using open source as much as possible. Luc P. Sent from my iPhone > On Jun 5, 2015, at 12:16, Colin Fleming wrote: > > I'm the author of Cursive, which I'm planning to sell and which will be > (mostly) closed source. What I don't see here is what would be the advantage > to me in using this license? I'm not releasing closed source because I'm > evil, but because I want Cursive development to be sustainable so I can > continue to develop it and my family can continue to eat and not live in > cardboard boxes. Charging for closed source software is the only realistic > model I can see that achieves this goal. > > I suspect the Datomic team's reasoning is similar - their pricing is far from > outrageous for the sort of product they're offering. What would be the > advantage to them in doing this? They would simply lose the ability to charge > in two years' time, and they would also lose the vast majority of their > clients who also wouldn't want to be bound by these restrictions. Nobody > wins, as far as I can see. > >> On 5 June 2015 at 22:17, Fergal Byrne wrote: >> >> An old-school C++ dev and I have started an initiative to combine the best >> of Open Source with a limited commercial license. It's not a new idea - >> MySQL creator Monty Widenius thought of something less viral in 2013 [1]. >> >> The Time-Bombed Open License [2] is the commercial side of a dual-licensed >> project, best paired with something strongly viral like GPL. Essentially, >> the project owner has 2 (up to 4) years to commercialise their product and >> then must go fully Open Source. The license is viral, so any commercial >> licensees must also use the TBOL and eventually open up their derived >> products. >> >> One major idea is to foster a culture of disruption of exploitative >> industries. If you can develop software to disrupt in your local market, >> your innovation can be used similarly by others elsewhere, and each new >> startup can improve on your work while earning their keep. Eventually, all >> derived products become Open Source and are free to all. >> >> We'd appreciate any comments, feedback and assistance from the wonderful >> Clojure community - we're up on twitter at @OccupyStartups. >> >> Regards, >> >> Fergal Byrne >> >> p.s. I wonder if this might be a solution to the clamour for Datomic to be >> Open Sourced (cough)? >> >> [1] >> http://monty-says.blogspot.ie/2013/06/business-source-software-license-with.html >> [2] http://occupystartups.me >> >> -- >> >> Fergal Byrne, Brenter IT >> >> http://inbits.com - Better Living through Thoughtful Technology >> http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne >> >> Founder of Clortex: HTM in Clojure - >> https://github.com/nupic-community/clortex >> >> Author, Real Machine Intelligence with Clortex and NuPIC >> Read for free or buy the book at https://leanpub.com/realsmartmachines >> >> e:fergalbyrnedub...@gmail.com t:+353 83 4214179 >> Join the quest for Machine Intelligence at http://numenta.org >> Formerly of Adnet edi...@adnet.ie http://www.adnet.ie >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- >
Re: [ANN] Clojure 1.7.0-RC1 now available
We have a planned upgrade at a customer site before xmas of our oldest product. Internal work on upgrading it to 1.7 starts in august. If I look at the Clojure upgrade track since 2009, I can't say that I am nervous about this. Not at all :) We are presently building a new product and integrating 1.7 made sense. We already reused some common internal components w/o any glitches. 25 years ago I was used to smooth upgrades working on VMS. I did not see that happening many times since then. And we run critical services 24/7 on premises, not in a fully controlled off-site environment. Our up times are insane. Yahoo ! Luc > On Jun 4, 2015, at 2:51 PM, Luc Prefontaine > wrote: > > Still 3 months away from production beta. > > I get twitchy if we go more than two weeks between production builds — but > then it’s the web :) > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-RC1 now available
Hi, Have been using 1.7 since beta1 in dev and test in a new dev. Still 3 months away from production beta. So far no issues. Zero, nada, nil, ... Reader conditionals are quite amazing, we started unifying backend and front end code. Wow... No more split brain syndrome and a huge simplification of front end/back end code. That's a huge relief on my nervous system :) For the first time in many years I enjoy working on a web front end... finally. Thank you all, Luc P. On Thu, 21 May 2015 11:30:47 -0500 Alex Miller wrote: > Clojure 1.7.0-RC1 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ > - Leiningen: [org.clojure/clojure "1.7.0-RC1"] > > The only change since 1.7.0-beta3 is CLJ-1706, which makes reader > conditional splicing an error at the top level (previously it would > silently drop all but the first spliced element). > > For a full list of changes since 1.6.0, see: > https://github.com/clojure/clojure/blob/master/changes.md > > Please give it a try and let us know if things are working (or not). > The more and quicker feedback we get, the sooner we can release 1.7.0 > final! > > - Alex > -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: +1 (514) 993-0320 Fax: +1 (514) 800-2017 Rabat, Maroc Mobil: +1 212 6 98 00 64 47 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Advice when running java -jar rather than a managed server like tomcat?
I like it when someone says 'do not do this' without some supporting cost/benefit rationale. My next question is why not ? I'll add my own salt here: - Daemonizing does not alter business logic, it can be kept separate using more than one entry point - Supervisory functions are not as generic as some may think. You may have a need to support extra stuff in daemon mode that may/may not be offered by your platform supervisor - Portability might be an issue which is easier to deal with within the JVM than having to cope with different platform specific supervisors As to the why not, I am eager to see them. In general your mileage will vary depending on your needs. This is the real answer to many of the 'do not do this' so named 'rules'. Luc P. Sent from my iPhone > On May 29, 2015, at 08:02, piastkra...@gmail.com wrote: > > Stuart, about the JSVC, I am curious if you have an opinion about the > argument made in the comments of this blog post: > > "Great post, but in reality you should never write app that daemonize them > self. Always use supervisors that your system provides." > > http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ > > > > > >> On Wednesday, May 27, 2015 at 3:53:24 AM UTC-4, Stuart Sierra wrote: >> JSVC (Apache Commons daemon for Unix) is excellent for this sort of thing. >> There's a Windows Services version too. >> –S >> >> >>> On Tuesday, May 26, 2015 at 12:38:30 PM UTC+1, Colin Yates wrote: >>> Hi, >>> >>> I am venturing into new territory using http-kit, as I usually use a >>> 'managed' web server container like tomcat and have a few questions about >>> packing and running a JAR file: >>> >>> - are there are convenient service wrappers for windows and/or Linux >>> - any best practice around managing class path for things like logback.xml >>> >>> I have a jar created from lein uberjar and java -jar the.jar works, but >>> this seems a long way away from automated deployment :). >>> >>> Any advice welcome - thanks! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using :refer 'sparingly'
We systematically use refer all on tools.trace and a few other of our name spaces used for production support. It becomes handy in a live repl in production. Luc P. > I agree with the general sentiment expressed here, but would just like to > add that `:refer`-ing a few frequently used functions (as Colin Yates > stated, particularly when it's assumed there is strong coupling or > closeness between the two namespaces involved), is a much more minor > nuisance than `:refer :all`. At least with `:refer [some-fn > some-other-fn]`, you _can_ figure out where the function came from by going > up to the `ns` declaration, and if you're fast with your editor, this is > easy to do. Both `:refer :all` and `:use`/ `(use)` should (IMHO) only be > used for hacking around at the repl. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Multimethod or protocol or...? Clojure design feedback
I regroup these name spaces in an api name space and require this name space where it makes sense. You can cut out your APIs as you wish around one or more mutli methods and add whatever stuff needs to be part of it. Still manually managed but not scattered everywhere. Never thought of a different way to manage this however. Luc P. > Thanks for the feedback guys. Another related Q: The user needs to require > the namespace that those defmethods are defined in for the multi to know > about it. Presumably each defmethods will be in individual files, meaning > the user has to require all those files for the migration tool to work. Is > there a cleaner way of make sure that the defmulti knows about those > methods? > > On Thursday, May 14, 2015 at 7:56:12 PM UTC-4, Jason Marmon wrote: > > > > I'm working on a tool to orchestrate the migration from mongodb to > > datomic, and i'm looking for a bit of design feedback as i'm new to > > clojure. > > > > > > The user needs to provide functions that transform mongodb documents into > > datomic txes. Do y'all prefer the top or bottom style, or think there's a > > different way to implement this design that might be better? > > 12345678910111213141516171819 > > > > ;; Multimethod for transforming data based on the name of the source > > mongodb collection > > (defmulti transform identity) > > > > (defmethod transform "events" [data] > >;; do something with data > > ) > > > > (defmethod transform "users" [data] > >;; do something with data > > ) > > > > ;; > > > > (defprotocol Collection-Transformer > >(transform [mongo-db document])) > > > > (def user-transformer > > (reify Collection-Transformer > > (transform [m d] "do stuff"))) > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CLJ-703 - 10x compilation time decrease after applying one-line patch, no downsides.
There's a better 'fix'. Run your builds on SSDs or on a memory based file system. With the RAM available these days, any build can be done on a memory based file system. It speeds up every step by a huge factor. Not only compilation. You only need to copy your targets to a 'permanent' place. We have been doing this for years to shrink build times. We AOT most of our code base. Luc P. > I'll just say one more time that the team should really consider doing > bug-fix releases in the future. This problem sounds serious enough to be > handled as quickly as possible. Clojure 1.6 was released over one year ago, > so I'm guessing 1.8 is more than a year away from now. Waiting for major > releases for a bug fix in not exactly the greatest user experience. > > On 9 May 2015 at 05:18, Alexander Hudek wrote: > > > I'd like to chime in here in support of this, our company has been running > > a modified clojure build because of this for over a year now. > > > > Alex > > > > > > On Friday, May 8, 2015 at 2:12:50 PM UTC-4, Martin Raison wrote: > >> > >> Hi all, > >> > >> This issue has been around for a while without much activity, although a > >> very simple fix is already there: > >> http://dev.clojure.org/jira/browse/CLJ-703 > >> > >> We have a pretty big Clojure project that we compile on machines with > >> slow hard-drives, on CentOS 6. We noticed that compilation had become > >> extremely slow, however CPU usage was always below 10%. > >> > >> Simply removing the line "cfs.getFD().sync();" inside > >> "src/jvm/clojure/lang/Compiler.java" > >> dramatically improved the compilation time (Something like 10x, although at > >> this level of increase, measurement almost doesn't make sense anymore :)). > >> > >> We've been using the suggested fix (remove-sync-only.patch) for a few > >> weeks and haven't observed any issues. > >> > >> It seems we should really figure out whether this line is actually > >> necessary, or if it was added there "just in case". Even if some situations > >> require it, the speed bump is so huge that we might want some special-case > >> logic. > >> > >> Martin > >> > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure.lang.LazySeq cannot be cast to clojure.lang.IFn
Dunno riemann but I would say that you need a closure here,
not an immediate call to notify. The closure will be called when expiration is
reached.
So use #(notify ...) instead.
In your current code notify gets called, return a lazy seq (for) and then
the lazy seq is called as a function when the service expires. Oups...
Second thing, use doseq, not for if you want the side effects do be done in
your notify fn. for will not get your side effects done, it only returns a lazy
seq.
Luc P.
Sent from my iPad
> On May 8, 2015, at 08:01, Alexey Astafyev wrote:
>
> I'm new to Riemann and Clojure. All I want to do is to send email
> notifications to three email groups when some service's TTL is expired. I
> created some sort of config file where I store a list of emails:
>
> {
> :email_group_1 (
> "fi...@example.com"
> "sec...@example.ru"
> )
> :email_group_2 (
> "th...@example.com"
> )
> }
>
> My riemann config looks like this:
>
> (logging/init {:console true})
> (import org.apache.log4j.Level)
> (logging/set-level Level/DEBUG)
>
> (require '[clojure.java.io :as io])
> (import '[java.io PushbackReader])
>
> (let [host "0.0.0.0"]
> (tcp-server {:host host :port 60001})
> (udp-server {:host host})
> (ws-server {:host host :port 60003}))
> (repl-server {:host "127.0.0.1"})
>
> (def cwd (System/getProperty "user.dir"))
>
> (def emails
> (with-open [r (io/reader (str cwd "/etc/emails.clj"))]
> (read (PushbackReader. r
>
> (periodically-expire 5)
>
> (def email (mailer))
>
> (defn notify [& egroups]
> (for [egroup egroups]
> (rollup 1 60 (apply email (emails egroup)
>
> (let [index (index)]
> (streams
> (default :ttl 60
> index
>
> (expired
> (where (service "service_connect_active")
> #(info "expired" %)
> (notify :email_group_1 :email_group_2))
>
> Code looks good (for me), but when this service is expired I get the
> following error:
>
> 09:45:39 riemann.1 | INFO [2015-05-08 10:45:39,313] Thread-5 -
> riemann.config - expired {:ttl 60, :time 357766884827/250, :state expired,
> :service service_connect_active, :host ava.local}
> 09:45:39 riemann.1 | WARN [2015-05-08 10:45:39,319] Thread-5 -
> riemann.config - clojure.lang.LazySeq@841649b8 threw
> 09:45:39 riemann.1 | java.lang.ClassCastException: clojure.lang.LazySeq
> cannot be cast to clojure.lang.IFn
> 09:45:39 riemann.1 | at
> riemann.config$eval66$stream__70$fn__75.invoke(riemann.development.config:34)
> 09:45:39 riemann.1 | at
> riemann.config$eval66$stream__70.invoke(riemann.development.config:45)
> 09:45:39 riemann.1 | at
> riemann.streams$match$stream__3514$fn__3525.invoke(streams.clj:1209)
> 09:45:39 riemann.1 | at
> riemann.streams$match$stream__3514.invoke(streams.clj:1209)
> 09:45:39 riemann.1 | at
> riemann.streams$default$stream__3731$fn__3742.invoke(streams.clj:1328)
> 09:45:39 riemann.1 | at
> riemann.streams$default$stream__3731.invoke(streams.clj:1328)
> 09:45:39 riemann.1 | at
> riemann.core$stream_BANG_$fn__4415.invoke(core.clj:19)
> 09:45:39 riemann.1 | at riemann.core$stream_BANG_.invoke(core.clj:18)
> 09:45:39 riemann.1 | at
> riemann.core$reaper$worker__4529$fn__4539.invoke(core.clj:303)
> 09:45:39 riemann.1 | at
> riemann.core$reaper$worker__4529.invoke(core.clj:297)
> 09:45:39 riemann.1 | at
> riemann.service.ThreadService$thread_service_runner__1973$fn__1974.invoke(service.clj:71)
> 09:45:39 riemann.1 | at
> riemann.service.ThreadService$thread_service_runner__1973.invoke(service.clj:70)
> 09:45:39 riemann.1 | at clojure.lang.AFn.run(AFn.java:22)
> 09:45:39 riemann.1 | at java.lang.Thread.run(Thread.java:745)
>
> Could someone please help me? Thanks.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop rece
Re: Clojure needs a web framework with more momentum
I certainly have some personality disorders, but I am not bipolar :) What am I ? Help ! :) Luc P. > > And never has this author proven that programmers with bipolar > personality are > > programming more LISP then other languages. > > It's a metaphor. The author is not actually diagnosing Lisp programmers > with bipolar disorder. The metaphor offers an image of a particular kind of > student who starts stuff but doesn't finish stuff. > > > > > On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote: > > > > No, it isn't. And never has this author proven that programmers with > > bipolar personality are programming more LISP then other languages. > > > > Many larger libraries in the Clojure community are well documented and > > "finished-off properly". > > > > Web frameworks have been tried and not been picked up. Users have chosen > > the modular compose it yourself approach. Framework authors have simply > > stopped maintaining what nobody wanted anyway or split them up into smaller > > pieces. > > > > > > On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote: > >> > >> > >> > The web development industry as reflected in job postings at > >> > Indeed.co.uk is still dominated by the likes of Rails, Django, > >> Laravel, > >> > Zend, Symfony & Spring so I'm not sure how you've concluded that > >> there's > >> > been a 15-year trend towards composition. > >> > >> That is a good point, though I would also point out that, according to > >> Indeed.com, the use of Clojure is also growing. To me, what's important is > >> the growth of the Clojure community, rather than the growth of some > >> sub-community focused on a particular niche. > >> > >> However, I acknowledge you may have a point about the failure of any of > >> the Clojure frameworks to take off. It's possible this is another > >> manifestation of the Bipolar Programmer problem: > >> > >> http://www.lambdassociates.org/blog/bipolar.htm > >> > >> "Brilliance and failure are so often mixed together and our initial > >> reaction is it shouldn't be. But it happens and it happens a lot. Why? > >> ...But brilliance is not enough. You need application too, because the > >> material is harder at university. So pretty soon our man is getting B+, > >> then Bs and then Cs for his assignments. He experiences alternating > >> feelings of failure cutting through his usual self assurance. He can > >> still > >> stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, > >> but what he hands in is not so great. > >> > >> ...So BBMs love Lisp. And the stunning originality of Lisp is reflective > >> of the creativity of the BBM; so we have a long list of ideas that > >> originated with Lispers - garbage collection, list handling, personal > >> computing, windowing and areas in which Lisp people were amongst the > >> earliest pioneers. So we would think, off the cuff, that Lisp should be > >> well established, the premiere programming language because hey - its > >> great > >> and we were the first guys to do this stuff. > >> > >> But it isn't and the reasons why not are not in the language, but in the > >> community itself, which contains not just the strengths but also the > >> weaknesses of the BBM. > >> > >> One of these is the inability to finish things off properly. The phrase > >> 'throw-away design' is absolutely made for the BBM and it comes from the > >> Lisp community. Lisp allows you to just chuck things off so easily, and > >> it is easy to take this for granted. I saw this 10 years ago when looking > >> for a GUI to my Lisp (Garnet had just gone West then). No problem, there > >> were 9 different offerings. The trouble was that none of the 9 were > >> properly documented and none were bug free. Basically each person had > >> implemented his own solution and it worked for him so that was fine. > >> This > >> is a BBM attitude; it works for me and I understand it. It is also the > >> product of not needing or wanting anybody else's help to do something." > >> > >> > >> > >> > >> > >> On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote: > >>> > >>> On 03/05
Re: Why is Caribou unmaintained ?
There's been no activity since a year ago. This may give the impression that it's dead and maybe it still quite alive. If people want a framework this one looks to be very complete. It would be a shame not to reuse all that brain power. More feedback ? > On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote: > > > > Spawned from the other thread about web frameworks. > > > > Can any of the original maintainers answer this one ? > > > > According to that same other thread, it has 2 developers on it, not 0. If > it's feature-complete 2 might easily be sufficient to field the occasional > bug report. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Why is Caribou unmaintained ?
Spawned from the other thread about web frameworks. Can any of the original maintainers answer this one ? Thank you Luc P. -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure needs a web framework with more momentum
+1 This exactly the kind of exercises that needs to done as part of a product design. New potential needs have to be foreseen at this stage, not 18 months after a first release. This is why I hate frameworks, they assume some of these decisions and it's not always stated clearly. Someone has to discover the sad effects and if you are not lucky, you're the 'king of the farce'. They lure you in a trap pampered with 'easy', 'obvious'... Until you have a need that cannot be met along the way. I read several comments about how easy it is to upgrade Rails. Either things have been improving at the speed of light or I am a complete idiot. My last upgrades from 2.x to 2.y have been nightmares, dependency hell multiplied by an unknown factor above 100... I would rather deal with an explicit dependency graph than work with magic stuff that eventually breaks in obscure ways after an upgrade and requires mods in remote places in foreign code. Luc P. > The thing that bugs me the most about these sort of conversations about > "best practices" is that they often present a set of solutions without > first analyzing the problem at hand. > > If I came to this mailing list and asked "I want to write a websever in > Clojure..what should I use?". The response would most likely be Ring + > Compojure. Okay, not bad options, but that recommendation has been given > with absolutely no analysis of what I'm trying to accomplish. What if I > need async? What if I need web sockets? What sort of connection load am I > expecting? Will my system handle mostly persistent connections (like > websockets or SSE), or will it be more canned (and cacheable) data? If > someone recommends Ring to me, I may be pigeonholed into some system I'll > have to refactor later. Perhaps the best option is Aleph or Pedestal. > > That's the real issue with canned responses like rails tutorial. They > assume my needs match your needs and match the needs of most people. That's > just not the best way to go about doing software development. And it's a > problem I've seen in so many areas of computing. > > I've lost countless hundreds of hours of my life to frameworks that default > to bulky serialization formats (like XML or JSON), or frameworks that > assume LAN connections to the servers, or frameworks that assume I won't be > using multi-threading, or frameworks that assume I won't try to load 10k > rows on a single page, or frameworks that assume any number of things. The > thing I love the most about the Clojure community is that, more than any > other community I've been a part of, they try to ask you to think before > you jump. > > So what I would recommend is more of a set of guidelines, and matrices. > List all the frameworks/libraries on one axis, and features on another, and > start commenting. Make a page like this: ( > http://en.wikipedia.org/wiki/Comparison_of_video_container_formats) > > Mention that Ring is well supported by the community, but doesn't work well > with fully async servers, mention that Aleph does all the async you need, > but is a bit non-standard. Mention that data.json is pure Clojure, but > cheshire is most likely faster. > > Just present the options, and let the users make up their own minds. You > don't understand the needs of all of your users. So don't try to solve > their problems, instead present them with options and let them make up > their own minds. I guarantee you that whatever tech you recommend to > someone, the won't like some aspect of it, so better to present them with > all the options and let them choose, then they can only blame themselves if > it doesn't work out exactly like they expected. > > > > On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria > wrote: > > > I would like to echo the sentiment expressed by several posters in this > > thread, but with a slight twist. A few years back I picked up Ruby and Ruby > > on Rails as the language/framework to create a website with moderate > > complexity and functionality. I did this without any prior experience with > > the language of framework. What allowed me to quickly pick up both was the > > excellent documentation around the language and framework. For example, > > with the information from http://guides.rubyonrails.org and the canonical > > application built in https://www.railstutorial.org one can acquire the > > necessary knowledge to develop highly functional websites. Branching out to > > leverage "non-canonical" libraries/products then becomes a fairly easy > > exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords, > > etc.). What allows that to happen i
Re: Clojure needs a web framework with more momentum
Here in Morocco, the dominant web technology is... PHP. Tadaaa ! The're not even considering Raills or anything more 'advanced' for that matter. It's really an evolution ladder. People got on the 'framework' 'one fit for all band after trying things like PHP, JSP, ... and now realizing that it does not solve the issues they just leave. It will certainly happened with PHP and Rails. These solutions are geared toward some specific problem scopes. As soon as the business needs outrun what they can easily solve you are short of something else. The industry has been searching for a silver bullet solution for decades. In the early 80s, late 70s, CASE tools were suppose to be that bullet, (basic stuff in today's world, git, ant, ). Open systems then picked up, blabla, None of that fully delivered their promises. Ever. They helped climb the ladder however. In small steps... And now we have these frameworks that supposedly can ease the pain in any circumstances. They do fill the role up to a certain glass ceiling, the unforeseen business needs that make them blow in pieces because they can't be easily stretched, twisted, bended, ... Each of these initiatives were motivated by software creation automating and supposedly shrinking the costs while trying to downplay the need for an essential ingredient... Us. Wetware. I think it's a mirage. Maybe the solution has been there for decades under our eyes. Human beings. Capable of assembling solutions grater than the sum of their parts. Capable of bending the software as needed to do new stuff instead of having to fully rewrite stuff because shoes are becoming to tight. In one word adapt. This assumes that you have components to build from and people that can compose them as needed. Not some kind of frozen approach in time to software development were roles are pre-assigned and any change outside of this limited scope becomes a challenge by itself. The 'structure' needed here has nothing to do with walls and concrete. We need brain power to tear down/recompose things and stop thinking that processes, normalization, herd tagging, etc can lead us to work more efficiently. Processes, conventions, ... may help but at a low scale. Not pushed by at the scale of the whole software industry like these days Variety is the key. Luc P. > On 03/05/2015 14:39, larry google groups wrote: > > The industry has been moving against frameworks for 15 years now. The > > peak of the monolithic framework craze was Struts, back in 2000. After > > that, people started craving something less bloated. That's why the > > whole industry was so excited when Rails emerged in 2004. Bruce Eckel > > summed up the sudden change of mood in his essay "The departure of the > > hyper-enthusiasts": > > > > http://www.artima.com/weblogs/viewpost.jsp?thread=141312 > > > > But after awhile, people began to feel that even Rails was bloated, > > which lead to the emergence of micro-frameworks like Sinatra. > > > > And then, continuing with the trend, we've seen the emergence of > > eco-systems, such as Clojure, that allow the trend to go further: > > Clojure supports such high levels composition that frameworks are no > > longer needed. And this is the direction the industry has been moving > > for the last 15 years. Clojure is simply out in front. Most languages > > don't allow this level of composition. > > > > The web development industry as reflected in job postings at > Indeed.co.uk is still dominated by the likes of Rails, Django, Laravel, > Zend, Symfony & Spring so I'm not sure how you've concluded that there's > been a 15-year trend towards composition. Ruby and Python have had > lightweight composable alternatives for many years but Rails and Django > still dominate. I'm not against the composition at all. I just think we > need more structured alternatives that we can at least brand and market > as well as teach to Clojure beginners. > > gvim > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, vi
Re: Clojure needs a web framework with more momentum
Business case... I have two business cases at hand. None can be done with frameworks w/o making the end products look like any other one in their respective space and having to bend to framework limitations. Being disruptive requires a different approach. Having to write all these individual libs ourselves would make these two product sets much more difficult to create. Experimentation would also suffer a lot. Now we have the elements to create new recipes instead of everyone eating the same dry cake that's been left on the shelf for a year. Aside from HR tagging, I see little value in a branded framework. Being reluctant to be part of a tagged herd, I can't agree with you :) But given my (bad) character this may explain that :) Luc P. > On 03/05/2015 00:53, Christopher Small wrote: > > I disagree with the premise entirely. I think that the Clojure community > > has just done a better job of building smaller, more modular tooling. > > And this is frankly something I prefer, and find refreshing in the > > Clojure sphere (as compared with my previous Rails webdev experience). > > > > Note that to put things on the same footing, you'd want to be noting > > that Luminus depend on Ring and Compojure, with commit counts 761 and > > 865 resp, and contributor counts 73 and 29 resp. > > > > I'm not saying that Clojure can't improve it's offering in web dev with > > added libraries etc, but I wouldn't want to see us move away from the > > modularity with which we've built things, because I think it's a win. > > > > Just my 2 c > > > > Chris Small > > Most decent web frameworks these days are built from modular components > so this distinction is a bit laboured. Rails is built on top of Active* > and Rack so the Ring/Compojure distinction is illusory. Laravel is built > on top of Symfony components it could be argued that Symfony has played > a similar role to Ring/Compojure in the PHP community. > > Clojure's modular approach is great but I just don't see the need to > polarise when there's such a strong business case for structured > frameworks. If you look at most of the jobs in web development at > Indeed.com they're almost exclusively framework-based. Modular is great > but it would also be nice to see a few more Clojure jobs advertised. > > gvim > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What is current "best practice" regarding exceptions?
1) no 2) no 3) yes at all cost 4) both, exceptions are logged with context (current bindings, etc) 5) undecided, under close examination however 6) never have to restart, we check what cause the error and correct it externally if required most errors are reported immediately, may depend on the failed process being critical or not. Up times above 250 days, restarts only required when upgrading stuff. Luc P. > > I'm curious, how are people in the Clojure community currently dealing with > exceptions? I have a diverse set of questions on this topic. > > 1.) How many have adopted an Erlang "die fast and restart" strategy? > > 2.) How many use something like Supervisor to spin up new JVMs? If not > Supervisor, then what? > > 3.) How many try to catch all exceptions and therefore try to keep the app > running under all circumstances? > > 4.) If you use something like Kafka to log events, do you use the same log > to track exceptions, or do you track exceptions separately? > > 5.) How many use a catch/restart library such as Ribol? > > 6.) In general, how bad do you expect things to be before you allow the > software to die, have Nagios send a pager alert to your sysadmin, drag them > out of bed at 3 AM, and have a human examine the issue and restart things > manually? > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Newbie question about filtrering defrecord
You mean the a1 record no ? > Hi! > > I'm new to clojure, and have problem understanding how to filter a list of > defrecords. > I have tried different variations on the following: > > (defrecord Ape [fname lname]) > (def a1 (->Ape "test1" "test2")) > (def a2 (->Ape "test3" "test4")) > (def alist '(a1 a2)) > > (filter #(= "test1" (:fname %)) alist) > > I expect the filter to match the a2 record, but I obviously do something > wrong and would appreciate any suggestion. > > Kind regards > Magnus Jäverberg > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
It's fun to see that vintage tools are so much appreciated these days :) Luc P. > Batsov, > > CIDER is the best Clojure IDE. ;) > > -- > @solussd > > > > On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov wrote: > > > > And CIDER isn't, right? I find this pretty insulting... > > > >> On 29 March 2015 at 13:47, Colin Yates wrote: > >> Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs. > >> > >> On 29 March 2015 at 09:54, Sayth Renshaw wrote: > >> > Hi > >> > > >> > I last learned clojure in 1.2. Just curious why Clojure hasn't developed > >> > as a go to for data science? > >> > > >> > It never seems to get a mention R,Python and now Julia get the > >> > attention. By design it would appear that Clojure would be a good fit. > >> > Is it a lack of libraries, ease of install, no good default environment > >> > (R Rstudio, IPython ) where as you would need to use emacs with clojure, > >> > or is there just a better default use of Clojure? > >> > > >> > Sayth > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Clojure" group. > >> > To post to this group, send email to clojure@googlegroups.com > >> > Note that posts from new members are moderated - please be patient with > >> > your first post. > >> > To unsubscribe from this group, send email to > >> > clojure+unsubscr...@googlegroups.com > >> > For more options, visit this group at > >> > http://groups.google.com/group/clojure?hl=en > >> > --- > >> > You received this message because you are subscribed to the Google > >> > Groups "Clojure" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an email to clojure+unsubscr...@googlegroups.com. > >> > For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to the Google Groups > >> "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure related articles on Semaphore Community
Nice to you to raise the flag :) Luc P. > Hi everyone, > > I wanted to share a few articles about testing and deployment of Clojure > applications that I wrote for Semaphore Community - > https://semaphoreci.com/community/tags/clojure. > > I plan to continue writing on those and other topics so I would love to > hear some feedback or ideas. What topics would you recommend me to explore? > Any questions you would like to be answered in the tutorial form? > > Thanks, > > Nebojša Stričević > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
Bought it myself too... If this is some kind of marketing stunt, it caught me off guard... (sic) Luc P. > The list is so cool that I think this discussion is actually part of the > book's marketing strategy. It worked! I just bought my copy ;-) > > On Thu, Mar 26, 2015 at 4:57 PM, Colin Yates wrote: > > > Hi Leonardo, I haven't read it yet but I am very much looking forward > > to it based on other people's responses :). > > > > On 26 March 2015 at 15:52, Leonardo Borges > > wrote: > > > Thanks everyone for the kind words! > > > > > > It makes it all worth it :) > > > > > > Cheers, > > > Leonardo > > > > > > > > > On Thursday, March 26, 2015 at 11:44:27 AM UTC-3, Shaun Mahood wrote: > > >> > > >> Just thought I would leave a quick note for anyone interested in the > > book > > >> (and hopefully get the thread back on topic). I'm about 1/3 through the > > book > > >> and have found it really well written and interesting so far. It's an > > >> excellent introduction to reactive programming in general and for > > clojure > > >> specifically, and is easy to follow for a relative beginner in both > > clojure > > >> and reactive programming. If you have any interest at all in the topic I > > >> highly recommend picking it up. > > >> > > >> Thanks for writing it Leonardo! > > >> > > >> On Tuesday, March 24, 2015 at 8:26:02 AM UTC-6, Leonardo Borges wrote: > > >>> > > >>> Hi all, > > >>> > > >>> Some of you may know that I have been working on a book for the better > > >>> part of last year. > > >>> > > >>> I'm happy to announce it has finally been published! Here's the link: > > >>> https://www.packtpub.com/web-development/clojure-reactive-programming > > >>> > > >>> I hope you find it useful! I've had a great time putting it together! > > >>> > > >>> Cheers, > > >>> Leonardo Borges > > >>> www.leonardoborges.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 > > > --- > > > You received this message because you are subscribed to the Google Groups > > > "Clojure" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to clojure+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > Hildeberto Mendonça, Ph.D > Blog: http://www.hildeberto.com > Community: http://www.cejug.net > Twitter: https://twitter.com/htmfilho > > -- > 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
Re: [ANN][book] Clojure Reactive Programming
Fine with me. Let's call it off. It's not either a forum about netiquette or about 'how bad this word/expression hurts anonymous people'. > Luc, you are missing the point: this isn't the forum for that > discussion regardless of how valid the points in that discussion are. > This is a _Clojure_ forum, not a 'what's wrong with the (technology) > world' forum, I would suggest this isn't even a 'how can Clojure fix > the world' forum. > > Luc, please read the various responses carefully - replying by > validating the points in your discussion/justifying your position is > missing the point, please do not reply until you understand that. > > I think we should just let this thread die, so I'm out. > > > On 26 March 2015 at 13:08, Luc Préfontaine > wrote: > > The 'attack' word is again a manifestation of extreme political correctness. > > > > I will argue that these technologies with their inherent complexity are > > creating huge > > bureaucracies to attract and hide unqualified/unskilled/uncommited/.. aka > > 'stupid' people > > from scrutiny. > > > > These environments have the perverse effect of encouraging people not to > > think > > too much at least not publicly because of that political correctness pushed > > to the limit. > > 'You are not a team player, blablablalbla...'. > > > > 'Stupidity' is not off topic here, not at all. It's been a plague for two > > decades in this industry > > as soon as demand increased for sotfware. It started to attract people mid > > 80s because of > > the promise to get a well paid job. Not because they had above average > > skills or had a keen > > interest in it. 'I do not need to understand technology, I'll be a manager > > in three years'. > > This a real quote from a colleague when I was quite green. > > > > Meanwhile HR replaced know-how by worthless tags (add water to this pouch > > and you will get a > > Java/Ruby/... asset) and processes hoping to use a Taylor approach to > > creativity like > > if we were building cars on an assembly line. > > > > Some would argue that without this enterprise mass market, we would not > > have the technology > > we have at hand these days. True. The industry has been recycling old > > concepts > > for 30 years branding them as new. Huge costs with incremental changes. > > > > This mitigated success is limited by this assembly line model. > > And unlike a car plant, it cannot be robotized. > > You need to change wetware... Hence the 'stupidity' factor discussion -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
The 'attack' word is again a manifestation of extreme political correctness. I will argue that these technologies with their inherent complexity are creating huge bureaucracies to attract and hide unqualified/unskilled/uncommited/... aka 'stupid' people from scrutiny. These environments have the perverse effect of encouraging people not to think too much at least not publicly because of that political correctness pushed to the limit. 'You are not a team player, blablablalbla...'. 'Stupidity' is not off topic here, not at all. It's been a plague for two decades in this industry as soon as demand increased for sotfware. It started to attract people mid 80s because of the promise to get a well paid job. Not because they had above average skills or had a keen interest in it. 'I do not need to understand technology, I'll be a manager in three years'. This a real quote from a colleague when I was quite green. Meanwhile HR replaced know-how by worthless tags (add water to this pouch and you will get a Java/Ruby/... asset) and processes hoping to use a Taylor approach to creativity like if we were building cars on an assembly line. Some would argue that without this enterprise mass market, we would not have the technology we have at hand these days. True. The industry has been recycling old concepts for 30 years branding them as new. Huge costs with incremental changes. This mitigated success is limited by this assembly line model. And unlike a car plant, it cannot be robotized. You need to change wetware... Hence the 'stupidity' factor discussion. Now if the anonymity thing bugs you, I can bring forward explicit names in this thread with the failing projects, budget, ..., just let me pull my notes here... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
I support your statement.
I am fed up by this extreme political correctness era.
This leads directly to auto censorship.
I met numerous 'anarchitects' who never had to bring an app from inception to
real life use but nonetheless where issuing 'profound' statements about the
last buzz word they
read from the news stand.
With unnecessary software complexity comes huge teams, dilution of
responsibilities and
expertise, aside from the one picked up through some headlines.
This leads to a lack of accountability overall.
No one is responsible, 'we followed best practices/processes according to {put
your favorite methodology name here}'
I saw 'anarchitects' fly out before integrated or acceptance tests because
they had realize that the monster they helped created could not lift from the
ground.
Human induced complexity killed it well before it started to breathe.
A kind of Frankenstein aborted experiments.
After spending zillions of customer $ of course...
If it swims like a duck, squeaks like a duck, walks like a duck, well it's a
duck.
Not some kind of abstract apparatus.
Nothing forces people to buy/listen to a book/news report/tv show/... if they
find it rude
or inappropriate to their taste.
They just have to zap like most of them are doing over any serious thinking
about
how they work, what's the purpose of it and what responsibilities comes with it.
It's already a miracle that some people are actually saying publicly what they
really think,
let's not try to cut their wings...
Pleasing the majority is the path to mediocrity.
Luc P.
> Trust me I have been using Scala + Akka + Play for past three years in
> production, and had to deal with tons of incidental complexity plus a lot
> of noise they introduce as my daily job (in my code as well as other
> developer's code). Now I am in the best position to judge and compare them
> with Clojure code that does similar job but ten times simpler (and I don't
> only mean 10 time less verbose).
> I am sorry but I need to confess that within past 15 years that I have been
> working with numerous architects most of them choose technologies only
> based on 1/2 hour googling or reading reviews (and I don't mean all
> architects are like this). In particular the one I rightly called ignorant
> did not even write a simple poc to use AKKA and java8 to see how code looks
> like.
> By pathetic technology (and I didn't mean java8) I mean a technology that
> you need to fish out less than 10 lines of business logic from 50 or more
> lines of noise introduced by Scala futures (in AKKA), Play promise redeems,
> matching classes (case classes in Scala)...
> Remember when first time Spring was introduced, the original goal was to
> take out all the noise and put them in XML file so the developer remain
> focused on business logic. Here we are 10 or so years later: lots of noise
> and complexity added to the code to do orchestration. This is work of
> intelligent fool... (look at Erlang which AKKA tried to copy, it does a
> powerful orchestration without introducing much complexity, this is touch
> of genius)
> These are the pain points in our field. I have deeply felt it and try to
> point out that the life does not need to be that hard.
> Clojure is the first real try in opposite direction (touch of genius)
>
> Thanks a lot
> Best regards
> Shahrdad
>
>
>
>
> On Wed, Mar 25, 2015 at 8:06 AM, Colin Yates wrote:
>
> > No - he is right, we just don't say it! Obviously I am kidding :).
> >
> > On 25 March 2015 at 11:51, Hildeberto Mendonça wrote:
> > > On Wed, Mar 25, 2015 at 12:14 PM, Colin Yates
> > wrote:
> > >>
> > >> Hi Shahrdad, just a point of etiquette, inferring that an architect is
> > >> ignorant because they chose Java8, Akka and play is full of assumptions.
> > >> Calling those technologies pathetic is very bad poor.
> > >>
> > >> As I like to quote "Any intelligent fool can make things bigger and more
> > >> complex... It takes rude manners, assumptions and a whole bunch of
> > >> numptiness to claim 'bigger and more complex' means the author is a
> > fool".
> > >
> > >
> > > That's why I love this community. Mutual respect is part of the
> > philosophy.
> > > :-)
> > >
> > > --
> > > 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 u
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3115
It's up the maintainers down the food chain to keep up with changes and yes there are timing issues, not all changes/fixes can be applied synchronously. That's the idea of having libraries instead of a monolithic soup of code. Applying your statement to technology in general we would still be using horse driven carts... I appreciate the life style of Amish communities and would certainly switch to it if I could. But that's not how my world is wired presently. Luc P. > On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote: > > > > Need more information. But that warning is most certainly not something > > emitted by the ClojureScript compiler. > > > > Make sure you can reproduce without whatever downstream tooling you may be > > using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues > > > > There's a good chance it's purely downstream and needs to be reported > > elsewhere. > > > > The only thing the OP changed was the version of cljs he was using, and his > project went from working to broken. This means that one of the changes in > the new cljs broke something. Whether it directly broke the OP's code, or > broke a library that the OP's project depends on, is immaterial; the > location of the breaking change was in cljs itself. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Disk based caching for Clojure app
We have been running builds on the same SSDs, doing intensive logging, ... for three years now. None deteriorated. Builds are mainly scrap & write thousands of small files plus a few big ones (the targets). Write speed makes a huge difference for this kind of task. Aws allows to get VMs with SSDs of decent sizes and not to store only the OS. I think they would restrict usage if rewrites were a huge concern... Luc P. > On Friday, March 6, 2015 at 3:16:09 PM UTC-5, Michael Blume wrote: > > > > Possibly stupid question: can you just pretend you have more memory than > > you do and let the operating system do the heavy lifting? > > > As in, put the swap partition on the SSD and jack up the virtual memory in > the OS config? > > Isn't it a bad idea to put swap on an SSD, because of the limited number of > times an SSD byte can be rewritten before it sticks permanently? Thus > making SSD more suited to storing stuff where speed counts, but which > doesn't change very much, like the operating system kernel and modules and > core libraries, plus your most often used applications? Then you get faster > boot and app-startup times without constant writes to the SSD (just when > something is upgraded). > > Of course, SSD being less well suited to frequently-written data would also > militate against using it for a cache managed by the application, rather > than by the OS ... > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: To the person who recently tried to post a message about using vert.x library
You got the name right but I am not the sender :) > I may have the name of that library incorrect. I was going through > messages to the Clojure group from new senders. I saw this message, and > was intending to approve it, but accidentally hit the 'report as spam and > block the sender' button. Ugh. My apologies. If you were the sender, and > you are reading this, please send me a private message so I can try to > figure out how to undo this. > > Thanks, > Andy > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Let bindings and immutability
Think about values first, symbols after. Symbols are accessory, not values, values are the only things that exist at runtime. Symbols are only there for you poor human (I include myself in this statement) to grasp roughly what is going on by tracking intermediate values with names. The names you choose are irrelevant except for your own comprehension. There are no containers per se that you can alter transparently. Some special constructs (atoms, ...) allow you to persist other values, obviously you need to name these constructs but they are not symbols, they are a special kind of value. Your code will need the value they persist, not the construct itself. (swap! is of limited interest if you never refer to the atom value). Top level vars are like the universe of values where your code will operate, a frame. Once set vars do not change. (Ok, some may use alter root but it should be reserved to specific occasions). It's all about values. This is the semantic shift compared to most languages. I do not even think about the underlying objects supporting values in Clojure unless I need to (extending with protocols, type hints, weird stack traces, ...). Implementation details :) As for interop, you enter the mutable world and the familiar rules apply here. The above 'cosmology' sums up how I think when I dive into some Clojure code and it works 99.5% of the time. There's no confusion. Luc P. > On 12/02/2015 01:53, Ben Wolfson wrote: > > The multiple-binding form of let can be recursively transformed into > > nested lets: > > > > (let [name1 value1 name2 value2 ... name value] body) > > > > > (let [name1 value1] (let [name2 value2] ... (let [name value] body))) > > > > All you're doing with your let form is shadowing the name; there's no > > mutation. If you had something like this: > > > > (let [x 1] > > (let [x (inc x)] > > (println x)) ;; prints 2 > > (println x)) ;; prints 1 > > > > it would be more obvious; it's less apparent in your case because > > there's no room for the extra forms. > > > > That explains it but I think Clojure's syntax is misleading here. > Without knowledge of this magic the mind doesn't readily translate: > > (let [x 1 > x (inc x) > x (inc x) > x (inc x)] > x) > > > into: > > (let [x 1] >(let [x (inc x)] > (let [x (inc x)] >(let [x (inc x)] >x > > The single bracket pair in the original leads the unwitting newcomer to > assume all the x'es are in the same scope. > > gvim > > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Extending the LispReader with "embeded language lorms"
I apologize to the readers that may have a hard time getting rid of the image of myself in a bath :))) Sorry :) > Hi, > > Nice feature if you write a spreadsheet app maybe. > Still wonder who would use a console to interact with a spreadsheet :)) > > Just kidding. > > Tagged literals are the way to go to extend the reader. > If lisp notation is so much a pain then build your own reader using a tool > like ... instaparse. > > Your proposal makes the reader something else than a simple lisp reader. > Much more harder to maintain. > > The day some 'custom extensions' break with your reader on steroids, the > maintenance nightmare will start. > > Having played in the past with configurable Lisp readers, I see were this can > lead us and it's not a smooth road. > > Clojure has been build from well focused individual components. > > Your current proposal is risky at best, and the benefits weak. > > As far as the parenthesis syndrome, > I have been exposing non-coders (illiterate in fact) to DSLs written with > parenthesis, vectors and so on for a while. > > Surprisingly to some, they did not barf at the syntax cues. They have been > modifying files with success for a while. > > That makes to me the direct support of DSLs by the reader less sexy. > > Nothing personal in the above comments, you wanted some feedback. Here it is. > > I am not saying that all your ideas are to dumped. It would be nice to have > parsers for tag literals like csv expressions and probably other ideas can > come out of your proposal. > > What I an trying to say is decompose and implement the worthwhile ones as > separate pieces that others can reuse. > > If some pass the test of time and general use then they may end up in some > contrib lib or in the core possibly. > > I apologize for typos, been typing ob my iPhone from my bath :) > > Luc P. > > > Not anybody? I'm a little puzzled: is this feature so useless? I thought > > embedding stuff like CSV data in Clojure code "as is" could be a nice > > feature. > > https://github.com/henrik42/extended-lisp-reader#parsing-csv > > No need to rewrite it in Clojure syntax/string literals or other forms. > > > > I think after having tagged literals (which still stick to Clojure > > forms/syntax) > > it could be the next step in building DSLs with Clojure. > > > > Henrik > > > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Luc Prefontaine sent by ibisMail! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Extending the LispReader with "embeded language lorms"
Hi, Nice feature if you write a spreadsheet app maybe. Still wonder who would use a console to interact with a spreadsheet :)) Just kidding. Tagged literals are the way to go to extend the reader. If lisp notation is so much a pain then build your own reader using a tool like ... instaparse. Your proposal makes the reader something else than a simple lisp reader. Much more harder to maintain. The day some 'custom extensions' break with your reader on steroids, the maintenance nightmare will start. Having played in the past with configurable Lisp readers, I see were this can lead us and it's not a smooth road. Clojure has been build from well focused individual components. Your current proposal is risky at best, and the benefits weak. As far as the parenthesis syndrome, I have been exposing non-coders (illiterate in fact) to DSLs written with parenthesis, vectors and so on for a while. Surprisingly to some, they did not barf at the syntax cues. They have been modifying files with success for a while. That makes to me the direct support of DSLs by the reader less sexy. Nothing personal in the above comments, you wanted some feedback. Here it is. I am not saying that all your ideas are to dumped. It would be nice to have parsers for tag literals like csv expressions and probably other ideas can come out of your proposal. What I an trying to say is decompose and implement the worthwhile ones as separate pieces that others can reuse. If some pass the test of time and general use then they may end up in some contrib lib or in the core possibly. I apologize for typos, been typing ob my iPhone from my bath :) Luc P. > Not anybody? I'm a little puzzled: is this feature so useless? I thought > embedding stuff like CSV data in Clojure code "as is" could be a nice > feature. > https://github.com/henrik42/extended-lisp-reader#parsing-csv > No need to rewrite it in Clojure syntax/string literals or other forms. > > I think after having tagged literals (which still stick to Clojure > forms/syntax) > it could be the next step in building DSLs with Clojure. > > Henrik > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Possible additions to tools.trace
Hi, Got your ticket notification, it's a busy week, beeing on the road most of it. I will look at it by next Sunday after crossing the Atlantic :) Luc P. > Hi all, > > I've proposed some changed to tools.trace and created an initial > implementation (linked in the JIRA ticket). > > http://dev.clojure.org/jira/browse/TTRACE-10 > > Thanks, > > Aaron > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
Obviously... user=> (= (byte 1) (short 1) (long 1) 1) true user=> http://clojure.org/rationale Language as platform vs. language + platform - Old way - each language defines its own runtime GC, bytecode, type system, libraries etc - New way (JVM, .Net) - Common runtime independent of language Clojure 'type system' embraces the platform it runs on with the exception of its own persistent data structures. It's not the other way around. On Fri, 23 Jan 2015 14:23:34 -0800 (PST) Fluid Dynamics wrote: > And this is not a typeless language, it is a strongly dynamically > typed language. > -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: (514) 993-0320 Fax: (514) 800-2017 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
Danger vs flexibility. < or > are safe. Should they throw an exception then ? Compiler in some older typed languages would warn you about testing equality between two float numbers irrelevant of their types but would be silent about other operators. Testing equality with floats is seldom used in the context of heavy computations. Testing against a range is often preferred. Money related apps use specific types to deal with rounding/truncating. This is why packed decimal was used intensively. You would always end up with two decimals. W/o having to care for the intermediate computation steps too much. Danger comes from ignorance. What you with it afterward is another story :) I would find it odd to see some operators throw such errors in a typeless language. > If the underlying argument is that it is horribly dangerous to mix floats > and doubles in your code, then maybe (<= (float 1.5) (double 1.5)) should > have the semantics of (.compareTo (float 1.5) (double 1.5)), i.e., throw an > error. > > I'm not certain that's a good idea for Clojure, but it does seem like the > logical outcome of this line of thinking. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
public class TestClass {
public static void equality () {
double dd = 3.5;
float ff = 3.5f;
System.out.println(String.format("dd vs ff == %b", dd==ff));
double dd2 = 3.2;
float ff2 = 3.2f;
System.out.println(String.format("dd2 vs ff2 == %b", dd2==ff2));
}
}
REPL output:
=> (idem.core.TestClass/equality)
nil
Console output:
nREPL server started on port 38698 on host 127.0.0.1 - nrepl://127.0.0.1:38698
dd vs ff == true
dd2 vs ff2 == false
We are talking about values as primitive types, not boxed values as objects:
The equals method for class Object implements the most discriminating possible
equivalence relation on objects; that is, for any non-null reference values x
and y, this method returns true if and only if x and y refer to the same object
(x == y has the value true).
=> (class (float 3.2))
java.lang.Float
=> (class (double 3.2))
java.lang.Double
Oupse... :)
Luc P.
On Fri, 23 Jan 2015 01:31:31 -0800
Mark Engelberg wrote:
> On Fri, Jan 23, 2015 at 1:10 AM, Luc Prefontaine <
> lprefonta...@softaddicts.ca> wrote:
>
> > Agree, it's broken... in java...
> >
>
> I think it's more frustrating in Clojure than in Java, though,
> because in Java you have those big, ugly type annotations on every
> single variable, input and output, so there's really no question when
> you're working with a mixture of floats and doubles. In Clojure,
> it's much easier for this kind of thing to slip into your program
> unnoticed. Call a couple of external libraries that produce floats
> or doubles -- Clojure will happily hide the difference from you and
> then you get burned.
>
> As I frequently find myself explaining to newcomers to Clojure, one of
> Clojure's biggest weaknesses is that it goes to great pains to hide
> type details (floats vs doubles, boxed vs unboxed, hash sets vs array
> sets, etc.) and every once in a while it really matters -- a lot --
> what the types actually are and there aren't many tools for
> discovering the flow of types through your code.
>
> So I wouldn't necessarily go blaming this on Java.
>
> Furthermore, I'm not so sure it is broken in Java:
>
> => (.equals (float 2) (double 2))
> false
>
> => (.compareTo (float 2) (double 2))
> ClassCastException Cannot cast java.lang.Double to java.lang.Float
> java.lang.Class.cast (Class.java:3258)
>
> So Java doesn't appear to transparently treat floats and doubles as
> equal (which is consistent with the fact that Java's hashes of floats
> and doubles can be different).
>
--
Luc Préfontaine
SoftAddicts inc.
Québec, Canada
Mobil: (514) 993-0320
Fax: (514) 800-2017
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
Well if it breaks elsewhere than in your code because you mix representations
and leak
them to some library in Java that you do not control I see my comments as
absolutely relevant.
It's not technical, it's failsafe. But that might not be of any interest to
your problem scope.
However it does interest me. Hiding odd behaviors when consistency can be
guaranteed,
I have no problem with that. Here to me its very clear that there is no
failsafe approach.
Clojure is hosted on a platform that does not provide the kind if consistency
you want.
Anything you can build to hide this in Clojure is like building a tower on
moving sand.
Mark has a valid point about type safety which helps a bit in Java but you can
dig
with google and you will find people that got bitten in Java by float/double
mixing
even with type 'safety'. So long for type systems, it cannot help you with
values that
'look' the same superficially but are internally different.
For some values, floats and doubles are equal because their internal
representations are the
same. For many other values it's not working.
I suggest some readings;
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
http://floating-point-gui.de/errors/comparison/
Then maybe we can bring this thread to an end.
> If there's a technical reason why Clojure can't return false for all =
> comparisons between floats and doubles, I'd like to hear it. Otherwise, I
> don't see how your response is relevant.
>
> > On Jan 23, 2015, at 3:10 AM, Luc Prefontaine
> > wrote:
> >
> > Agree, it's broken... in java...
> > Has it has been broken in the past in several architectures...
> >
> > I understand your frustration but this is not something new. It's been a
> > problem for at least 30 years.
> >
> > It is kind of a basic programming issue:
> >
> > - Never compare floats with different representations.
> >
> > - Never mix different representations in computations
> >
> > - Convert representations as early as possible to a common format
> >
> > These are the rules to follow to avoid running into trouble.
> >
> > Now if you think you can overcome this persistent (ah ! ah !) problem with
> > some David Copperfield trick, fine.
> >
> > But that's a trick nothing else. The problem will resurface in some form in
> > another. Better cope with reality...
> >
> > Luc P.
> >
> >
> >> On Jan 23, 2015, at 1:33 AM, Immo Heikkinen
> >> wrote:
> >>>
> >>> I actually ran into this while comparing nested data structures from two
> >>> different sources and spent a good part of my day figuring out what's
> >>> happening. While it is a good advice to avoid mixing floats and doubles,
> >>> it is inevitable that Clojure users will get bitten by this once in a
> >>> while and hours will be wasted.
> >>>
> >>> It is also very disturbing to realise that "(= a b)" doesn't always imply
> >>> "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
> >>
> >> (inc)
> >>
> >> This is fundamentally broken behavior. Telling people to just learn to
> >> avoid it is not good, IMO. If the hashes must be unequal, then = should
> >> return false.
> >>
> >> As for backwards compatibility, note that if such a change were made to =,
> >> it wouldn't affect anyone who was already following Andy's advice to avoid
> >> mixing doubles and floats. IOW, it should only affect those who are doing
> >> something you're not "supposed" to do anyway.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> > --
> > Luc Prefontaine s
Re: Set equality bug?
Agree, it's broken... in java...
Has it has been broken in the past in several architectures...
I understand your frustration but this is not something new. It's been a
problem for at least 30 years.
It is kind of a basic programming issue:
- Never compare floats with different representations.
- Never mix different representations in computations
- Convert representations as early as possible to a common format
These are the rules to follow to avoid running into trouble.
Now if you think you can overcome this persistent (ah ! ah !) problem with some
David Copperfield trick, fine.
But that's a trick nothing else. The problem will resurface in some form in
another. Better cope with reality...
Luc P.
> On Jan 23, 2015, at 1:33 AM, Immo Heikkinen wrote:
> >
> > I actually ran into this while comparing nested data structures from two
> > different sources and spent a good part of my day figuring out what's
> > happening. While it is a good advice to avoid mixing floats and doubles, it
> > is inevitable that Clojure users will get bitten by this once in a while
> > and hours will be wasted.
> >
> > It is also very disturbing to realise that "(= a b)" doesn't always imply
> > "(= (hash a) (hash b))" or "(= #{a} #{b})" as you would think.
>
> (inc)
>
> This is fundamentally broken behavior. Telling people to just learn to avoid
> it is not good, IMO. If the hashes must be unequal, then = should return
> false.
>
> As for backwards compatibility, note that if such a change were made to =, it
> wouldn't affect anyone who was already following Andy's advice to avoid
> mixing doubles and floats. IOW, it should only affect those who are doing
> something you're not "supposed" to do anyway.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Luc Prefontaine sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Set equality bug?
And how to you want to proceed knowing that floats and double can escape
elsewhere in your app and create the same chaotic effect like for example,
in some interop call to some obscure library ?
The best ... consistency here seems to reflect what's occurring underneath
instead
of giving the false impression that everything is fine.
Floats and doubles do not have the same precision/representation and thus
comparing
for equal values without explicit casting/truncating/rounding cannot be relied
on.
These are JVM native types. Even Java folks ask this question about equality on
a regular
basis and its their language of choice :)
Have a look at IEE floating point representations that will give you an idea of
the scope
of the problem.
In the past I used to deal with up to 4 different representations on the same
hardware.
We would never mix them, we would convert them at the edge of our app or within
very narrow boundaries.
Even business apps in Cobol had issues with this, not all hardware supported
packed
decimal operations, relying on some floating point representation better
handled by
hardware was common with all the conversion problems related
(rounding/truncating
in computations, ...). We could even choose the runtime float representation to
minimize errors in computations and take the best one given the app at hand.
Avoid mixing them. That's the only safe escape.
Luc P.
> My one cent:
>
> But I think (and it's just my humble opinion) is in the scope of Clojure
> keep its consistency, am I right?
>
> I mean, if doubles and floats are different, and they are, I think we
> should always get equality test as false. Or always as true, if they're
> nominally the same value.
>
> Regards
>
> Plínio
>
> On Thu, Jan 22, 2015 at 12:18 PM, Andy Fingerhut
> wrote:
>
> > "It is out of scope for Clojure to fix this for Java types Float/Double"
> > -- comments in CLJ-1036: http://dev.clojure.org/jira/browse/CLJ-1036
> >
> > Andy
> >
> > On Thu, Jan 22, 2015 at 5:53 AM, Nicola Mometto
> > wrote:
> >
> >>
> >> Not sure if this is intended behaviour:
> >> user=> (= (float 1.6) (double 1.6))
> >> false
> >> user=> (= (float 1.5) (double 1.5))
> >> true
> >>
> >> I.e. = (and ==) will return true when comparing floats with doubles IFF
> >> the float's .doubleValue roundtrips to the same double it's comparing to.
> >>
> >> user=> (.doubleValue (float 1.6))
> >> 1.60023841858
> >> user=> (.doubleValue (float 1.5))
> >> 1.5
> >>
> >> I'm not sure why floats are not handled specially in Numbers.java so
> >> that hash/comparision is handled consistently with doubles (e.g. by
> >> converting the floats to the fitting double via Double.parseDouble),
> >> the current behaviour seems odd to me.
> >>
> >> Jozef Wagner writes:
> >>
> >> > More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036
> >> >
> >> > On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto
> >> wrote:
> >> >
> >> >>
> >> >> Looking at the PHM impl, this looks like it's caused by (float 0.5) and
> >> >> (double 0.5) hashing differently.
> >> >>
> >> >> user=> (= (float 0.5) (double 0.5))
> >> >> true
> >> >> user=> (map hash [(float 0.5) (double 0.5)])
> >> >> (1056964608 1071644672)
> >> >>
> >> >> Nicola Mometto writes:
> >> >>
> >> >> > Looks like it's a bug in PersistentHashMap:
> >> >> > user=> (contains? (hash-map {:a (float 0.5)} 1) {:a (double 05)})
> >> >> > false
> >> >> > user=> (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
> >> >> > true
> >> >> >
> >> >> > Immo Heikkinen writes:
> >> >> >
> >> >> >> (= (float 0.5) (double 0.5))
> >> >> >> => true
> >> >> >> (= #{(float 0.5)} #{(double 0.5)})
> >> >> >> => true
> >> >> >> (= {:a (float 0.5)} {:a (double 0.5)})
> >> >> >> => true
> >> >> >> (= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
> >> >> >> => false
> >> >> >>
> >> >> >>
> >> >> >> Tested with both 1.6.0 and 1.7.0-alpha5.
> >> >>
> >> >> --
> >> >>
> >> >> --
> >> &
Re: [ANN] dformat 0.1.0
Euuh ? I was expecting to find %5 and above and a bunch of embedded forms -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha5 now available
So far so good, will go in prod with it next Wednesday. Will run some heavy integrated tests in the next 48 hours. Will report if anything shows up. Thank you, Luc P. > For my projects swapping 1.7.0-alpha4 -> alpha5 has not culminated in any > abnormalities. So... looking good thus far on my end. > > On Sunday, January 11, 2015 at 11:45:50 AM UTC-5, Plinio Balduino wrote: > > > > Hi there, Alex and Clojure team > > > > Is there a planned date for the stable version release? > > > > Regards > > > > Plínio > > > > On Sun, Jan 11, 2015 at 12:34 PM, Alex Miller > > wrote: > > > >> I would greatly appreciate hearing any feedback about this (or any other) > >> alpha, even if it's just: everything looks ok. > >> > >> We've had a couple of regressions reported and that is hugely helpful as > >> we can quickly turn around fixes for the next one. > >> > >> Interested particularly in: regressions, performance +/-, and for this > >> alpha, AOT. > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clo...@googlegroups.com > >> > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+u...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to the Google Groups > >> "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to clojure+u...@googlegroups.com . > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: how do you name your protocols?
I do this when there is added value, like sone common logic I can wrap on top of the protocol methods that I do not want to call/duplicate in every implementation. But this is quite specific to my own app. The lifecycle's only purpose is to be extended to your own components. Can't see what would be the added value here, the wrapping fn would only be calling the protocol method. Nothing else... If you require more in your context then define your own wrapper. Nothing generic can help you at this point... I think... Luc P. > I was just refering to the fact that the 'start' protocol method is meant > to be called directly by library's users. > I'm not using components in any of my projects, so take it with a grain of > salt. It seems to me that it would be better (i.e. less coupled, fewer > assumptions about the starting process for implementers, more freedom for > Stuart to introduce non-breaking implementation changes) to have a > dedicated start function, that in its simplest form would just call > Lifecycle/start method. > > Jozef > > On Mon, Dec 29, 2014 at 3:40 PM, Malcolm Sparks wrote: > > > I agree with you and Meikel's points about wrapping protocols with API > > functions, it makes sense, especially if you want to combine these calls > > with (Prismatic) schema checks. > > > > However, I'm not sure about your point that Stuart made an 'unfortunate' > > design to 'expose' protocol methods directly, it's just a necessary > > consequence of the component design, unless you can suggest an alternative > > approach. > > > > On Sunday, 28 December 2014 16:54:30 UTC, Jozef Wagner wrote: > >> > >> I was not implying anything about what Rich have said. While the SPI > >> term may be used in the 'enterprise' field too much (and in an unnecessary > >> complicated manner), I think it has perfectly valid uses in Clojure. The > >> API tells you what a function or a macro does for you, but SPI tells you > >> what you have to do in order to integrate with existing functionalities. > >> > >> BTW I think protocol methods should be in SPI too. (Stuart's components > >> library made IMO a bit unfortunate decision to expose 'start' and 'stop' > >> protocol methods directly) See http://kotka.de/blog/2011/ > >> 07/Separation_of_concerns.html for a related write-up. > >> > >> Jozef > >> > >> On Sunday, December 28, 2014 4:18:47 PM UTC+1, adrian...@mail.yu.edu > >> wrote: > >>> > >>> You're overlooking the fact that a "service provider interface" is > >>> simply enterprise design pattern jargon for a subset of public APIs that > >>> expose the underlying interfaces of the library to consumers. Saying that > >>> Rich is saying protocols should "never ever" be part of the public API is > >>> both misleading and false. > >>> > >>> On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote: > >>>> > >>>> Protocols should never ever be part of public API. Protocols can be > >>>> part of the SPI, if custom extensions are to be supported. Otherwise they > >>>> are an implementation detail. See Rich's talk at 4:30 http://vimeo.com/ > >>>> 100518968 > >>>> > >>>> Jozef > >>>> > >>>> On Sun, Dec 28, 2014 at 8:11 AM, Mikera wrote: > >>>> > >>>>> That depends if the protocols are part of your user-facing API or not > >>>>> - a lot of the time I find that protocols are best hidden as > >>>>> implementation > >>>>> details rather than exposed to users. > >>>>> > >>>>> In core.matrix, for example, users never see the protocols directly: > >>>>> only implementers of new matrix libraries need to care > >>>>> > >>>>> On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote: > >>>>>> > >>>>>> Changing old protocol names should trigger a major revision change in > >>>>>> the minimum because it breaks backwards compatibility. > >>>>>> > >>>>>> --Ashton > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> > On Dec 27, 2014, at 11:18 AM, Michael Klishin < > >>>>>> michael@gmail.com> wrote: > >>>>&g
Re: Clojure Style Guide
Defaults only please. There are more pressing needs from dev tools than this sort of thing. Diversity is what makes us well... different. Our minds are not formatted the same either. What may look readable to someone may look like garbage to someone else, the context may also influence comprehension. If a business wants a more or less strict code style fine. It may well be a decent requirement given their domain. If they need to tweak 50 variables it's also fine, it's an investment they are willing to make. At various times in the past, focus has been on 'standardizing' how code is written, up to choosing variable names, presentation, ... While this may have been valuable in some contexts, no unique agreement has been ever adopted and the impact on software quality is nil. It may help a given team to agree on some conventions but in the large it's not worth the energy it sucks. I suggest reading a 'Brave New World' for those who think that a stronger initiative than defaults is required :) Or punch out a few thousand cards of Cobol code lines to get the feeling... Luc P. Sent from my iPad > On Dec 20, 2014, at 09:57, Colin Fleming wrote: > > Yes, perhaps just agreeing on sane defaults is a more achievable goal. > Cursive currently does not indent everything exactly according to the guide > by default. I would also not like to see tools' ability to implement more > sophisticated formatting hampered by an overly restrictive guide either, > since a lot of users have requested that Cursive do different things with > particular forms, but having agreed defaults doesn't conflict with this. > >> On 20 December 2014 at 22:51, Laurent PETIT wrote: >> I agree that if all tools could agree on sale out of the box defaults, this >> would be very valuable to users and clojure in general. >> >> Maybe a less ambitious goal than getting the whole community agree on >> standards could be tool authors to agree on shared defaults. Which of course >> doesn't prevent the tools to offer additional options, but activating those >> would require users to explicitly customize the tools settings. >> >> Le samedi 20 décembre 2014, Lars Andersen a écrit : >> >>> My view on this is very much along the line of discussions about >>> whitespace. While I have opinions about these matters, for the most part I >>> don't want to think about it--I have more pressing concerns. What's >>> important to me is consistency within a code base. Just like with >>> whitespace, I don't want to introduce spurious changes into all my diffs >>> when working with other people. I also don't want to customize 50 editor >>> variables to get sane defaults which I have to tweak for various >>> environments (work, home, contributing to open source projects). >>> >>> Supporting different styles is a laudable goal, but I hope we can agree >>> that the defaults should be similar in all editors to reduce friction when >>> working with others. Using a style guide maintained by the community for >>> those defaults make a lot of sense to me. >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Laurent Petit >> >> -- >> 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"
Re: clojure.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?
Dunno the answer but I know how many buddhist monks are needed, exactly three: a) the first one readies itself for the bulb swap! by repeating a mantra b) the second meditates to make the first monk levitate toward the fixture c) the third one immolates itself to provide light for the entire duration of the operation Sorry for all the buddhist monks that may be offended by the above :) I like black humor very much and this is probably the only joke that I can write on this list that will not qualify me hopefully for eternal damnation... Euh moderation... Luc P. Sent from my iPad > On Dec 8, 2014, at 20:11, Matching Socks wrote: > > How many programmers does it take to change a light bulb?! > > http://dev.clojure.org/jira/browse/CLJ-1611 > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Thnx for clojureconj videos !!
+1, could not make it to Washington, my agenda was tossed upside down last week but with these at least I am not missing all of it. Thank you, Luc P. > Thank you very much for clojureconj videos !! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha3 now available
Encrypted fs have a file path limit around 140 bytes vs 255 w/o encryption. I hit this problem a couple of months ago with a library and AOT. The library had pretty long fn signatures, some generating class file names around 110 bytes long. The author tweaked these a bit to shorten the class file name. If I recall most of these where anonymous fns. With 140 (143 in my case) bytes you have to shorten the folder path as much as you can if you expect compilation to succeed and avoid fns with complex signatures. Luc P. > I hit this error when moving to a new box that had an encrypted FS. Might > be related to your case as well. Good luck. > > On Wednesday, October 29, 2014 1:34:28 AM UTC+11, Stefan Kamphausen wrote: > > > > Hi, > > > > have there been any changes how fns with a name and recursion are > > compiled? One of my projects has a function which does not compile with > > 1.7.0-alpha3 anymore, but did fine with 1.6.0. > > > > I tried to create a minimal example at > > https://github.com/ska2342/nested-fn-breaks-clojure-17 > > > > (I know the function itself is probably stupid, I just wanted to > > demonstrate the case. I don't know if it even runs.) > > > > Compilation breaks with a java.io.IOException: File name too long > > > > > > The problem seems to be the combination of > > > > * using a long function name (not a bad thing per se), > > * using a rather long name for a local binding (not common in > > Clojure-land, used in my case for documentation of the intent of the anon > > fn), > > * and using a name for the anonymous function (needed for recursion and > > usually a good idea because it improves stacktraces, but maybe you added > > the local binding to the name for exactly that reason). > > > > Regarding the second (long var binding name), my original function uses > > shorter names, but has some nested constructs (for, cond, ...) which seem > > to make the name larger, too. There is really nothing unusually long there. > > > > Of course, I can work around this by using different names, factoring an > > inner anon function out to a defn and probably in other ways. I just > > wanted to make sure, that you are aware that problems like this may show up > > and made the change on purpose. > > > > > > Thanks, > > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CCW bug [SEVERE]
I'll repeat myself : '...guessing which error is relevant or not is an educated guess at best except if you are deep in Eclipse plugins coding.' Laurent stated clearly that saving a file triggers a number of things in several plugins. There could be suspicious messages in the log that have nothing to do with CCW and that could give an idea of the root of the problem. I'll leave you to think about this and figure out what should be your next action. Guess what ? It's not adding another email to this thread, I wrote 'action' above. Luc P. > On Friday, October 31, 2014 6:23:42 PM UTC-4, Luc wrote: > > > > Just curious, how can you expect a fix if you do not provide any > > information that > > could support a serious investigation ? > > > > I read the eclipse log file from time to time and guessing which error is > > relevant or not is an educated guess at best except if you are deep in > > Eclipse plugins coding. > > > > Creating an issue in the ccw project page takes under a minute including > > attaching > > the log file. > > > > If you expect the developer to find the root cause from thin air, you will > > wait > > for eternity. Laurent is very proactive in investigating problems but w/o > > any grounds, > > he's better having a glass of wine than trying to guess what happened > > here. > > > > I would do the same... > > > > It's not *my* fault the log file doesn't contain anything unusual between > before the hang happened and after recovery. If CCW didn't log anything > that helps indicate what was different or unusual on that occasion of > saving, then there's simply not much I can do about it. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CCW bug [SEVERE]
Just curious, how can you expect a fix if you do not provide any information that could support a serious investigation ? I read the eclipse log file from time to time and guessing which error is relevant or not is an educated guess at best except if you are deep in Eclipse plugins coding. Creating an issue in the ccw project page takes under a minute including attaching the log file. If you expect the developer to find the root cause from thin air, you will wait for eternity. Laurent is very proactive in investigating problems but w/o any grounds, he's better having a glass of wine than trying to guess what happened here. I would do the same... Luc P. > On Friday, October 31, 2014 2:24:04 PM UTC-4, Laurent PETIT wrote: > > > > Also, if you can attach the workspace's .metadata/.log file, I can take a > > look at it. > > > > I have no idea how to reproduce it, which is part of the problem: I don't > know what to avoid doing, in order to ensure it doesn't happen again until > an update to CCW fixes it for good. > > As for that log file, I had a look and there's nothing that identifies the > problem. The log entry immediately prior to the hang is a complaint that > some map literal has an odd number of forms, which I must have left > incomplete when I went to make that other edit. There are lots of other > similar entries, probably from other times I saved while there was a > half-written map literal on my to-do stack, and it didn't hang on any of > those other saves. The log entry immediately following that one is a > session start message. So whatever was different that one time does not > show up in the log, unfortunately, rendering the log unhelpful in this > instance. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: where do I think the wrong way
You need to provide a key and a value. (assoc book :authors (conj ... LP > Thanks James, > > But how do I use assoc with it > > I tried this : > > (defn add-author [book new-author] > (assoc book (conj (book :authors) new-author))) > > but then I see this message : > > ArityException Wrong number of args (2) passed to: core$assoc > clojure.lang.AFn.throwArity (AFn.java:437) > > Roelof > > > Op woensdag 29 oktober 2014 12:08:35 UTC+1 schreef James Reeves: > > > On 29 October 2014 11:01, Roelof Wobben > > > wrote: > >> > >> For a exercise I have to add something to the end of a existing map. > >> > >> So I thought this would work : > >> > >> (defn add-author [book new-author] > >> (assoc book (conj :authors new-author))) > >> > > > > Take a look at that conj expression on its own: > > > > (conj :authors new-author) > > > > You're trying to conjoin "new-author" onto the keyword :authors, but > > keywords aren't collections. That's what the error means. It's saying that > > it expected a collection, but you've supplied a keyword instead. > > > > What you want is: > > > > (conj (get book :authors) new-author) > > > > Which can also be written: > > > > (conj (book :authors) new-author) > > > > (conj (:authors book) new-author) > > > > These two expressions are shortcuts for the above "get" function. They > > work because maps and keywords can act as functions. > > > > - James > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CCW bug [SEVERE]
Ka-plonk :) > Do the names Ken Wesson or Cedric Greevey mean anything to you? Just > checking. > > On Tue, Oct 28, 2014 at 1:28 PM, Fluid Dynamics wrote: > > > On Tuesday, October 28, 2014 12:19:29 PM UTC-4, Marcus Blankenship wrote: > >> > >> Agreed. I've been amazed at how kind this group has been, despite your > >> attitude of disrespect toward them. > >> > >> On Tue, Oct 28, 2014 at 9:09 AM, Dylan Butman wrote: > >> > >>> From your attitude and lack of respect for the very knowledgeable, > >>> experienced, and respectful people here trying to help improve and > >>> understand the short comings in your current workflow, I'd say you might > >>> be > >>> walking to work in the near future. Parking's free that way. > >>> > >> > > Really? Because I'm not the one who accused someone of nonexistent > > "shortcomings" and then made the impotent threat to revoke someone's > > driver's license -- and then had his threatening post deleted by the > > moderator. Hmm. :) > > > > Meanwhile, I think some people still have not grasped the scale of what > > I'm doing, namely how small it is. Small, experimental, limited to one > > person, and so forth. Version control, I repeat, would be MASSIVE overkill > > under the circumstances. It would make barely any less sense to reach for > > version control before writing a "hello, world" program. > > > > IF the project grows enough and is successful enough, then I might > > consider creating a github account and basing it there. But right now > > things are NOWHERE NEAR that kind of state. I am unsure how else to try to > > communicate the fact of how small, unpublishable, and etc. it is at this > > stage, so I will probably give up on anyone here who still seems to think > > it's big enough, has enough developers, or whatever to benefit from version > > control. It's not. So far there's two files of combined size 1200 lines, > > most of them comment and docstring lines. There might be as many as 200 > > actual lines of Clojure in there so far. Using a version control system, > > and dealing with all of the associated ceremony and formalities, would be > > like renting a factory and setting up all of the process monitoring, > > conveyor belt equipment, robot arms, safety inspections, permits, and > > everything else attendant the use of such a facility, just to put together > > a high school shop project wooden birdhouse to hang from a tree in my own > > back yard. :) It would be like filing a flight plan with the FAA before > > going to the city park with a kite. Like getting in the car and driving to > > the house next door to visit the neighbors for coffee. Like bringing a map, > > compass, pack full of survival supplies, camp stove, satellite phone, > > avalanche beacon, ropes, pitons, and sturdy hiking boots to take a walk in > > NYC that crosses through Central Park. Like commissioning the Glomar > > Explorer to fish a ring out of a toilet bowl. Bringing lawyers and pages of > > CYA contract text to a negotiation with a Starbucks for the purchase of a > > latte. Taking out a business license and city zoning permit to open a kid's > > five-cent lemonade stand. Seeking an import license before bringing a > > couple of Disney T-shirts back from EuroDisney. Requiring a full credit > > check before loaning your neighbor a screwdriver. Using steel-reinforced > > concrete to build a sandcastle. > > > > I trust everyone now gets the picture, and that any exception is named > > Sheldon Cooper? :) > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group.
Re: CCW bug [SEVERE]
a) you should rant about programmer(s). Exactly which one 'made a mistake' remains to be proven. b) Eclipse is a complex IDE, CCW runs on top of it as a plugin, it's at the mercy of the other pieces it depends on to run correctly. Stating who made the mistake requires some deep digging. c) If you added other plugins to the base image from the CCW download site, you just added more programmer(s) to the list above of potential 'culprits'. d) If your project is in automatic build mode then it's a build issue, as soon as you save it rebuilds. That is an order of magnitude more complex than saving a file. e) your context is an important factor of stability/instability and that cannot be foreseen by the 'programmer(s)' in every cases. f) reporting the problem might be a pain in the ass to you but this how software improves. You can yell as much as you can privately, it may help get the pressure down. I often do :) Publicly it's something else. You better be certain that it will help things rolling faster. Here it's obvious that it does not help anyone, you the less. When you are paying a huge amount of money, you can legitimately yell at your suppliier. Most clients don't which is odd considering the pile of crap shipped by many software suppliers. In the open source world, you do not have this leverage and if you do not report the issue nothing will ever happen to solve it. Luc P. > On Sunday, October 26, 2014 2:07:16 AM UTC-4, David Della Costa wrote: > > > > Here's the counterclockwise project home page, as far as I can tell: > > > > https://code.google.com/p/counterclockwise/ > > > > Issue tracker: > > > > https://code.google.com/p/counterclockwise/issues/list > > > > Users google group: > > > > https://groups.google.com/forum/#!forum/clojuredev-users > > > > I think you'd get a lot more mileage by posting something there, > > > Doubtful, since I didn't get anything really detailed like a stacktrace > And, I don't really feel much like inventing *yet another* user/pass for a > likely one-off post to some place. If you want to maximize reporting > through the formal system I recommend making the process as frictionless as > possible but the general trend for the past decade has been the exact > opposite (remember when bugs.java.com could be reported to anonymously, > just point click type?) > > This is a really weird one, when you think about it. How the heck does a > programmer make a mistake that results in the *file save* function going > into an *infinite loop*? At least it didn't go into an infinite loop > filling my filesystem... > > and I think you'd also get a better response if you could express the > > problem > > you're having calmly (i.e., leave off the all caps and "goddamn save" > > language). > > > No. When something comes within a hair's-breadth of not only costing a user > unsaved changes, but even previously saved changes, nearly destroying data > on the disk where it *should* be safe, then extra emphasis and urgent tones > are emphatically called for. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Demoralising experience trying to install on Win 7
Microsoft not wanting to confuse the end user ?!?!?!? I am baffled :))) Luc P. > I'll take a wild guess and say the "flashing" properly is a console with a > message Microsoft don't want to confuse you with. > > That said, the message i get here, is that wget is missing. Leiningen ships > with curl.exe. > > Not knowing any bat syntax at all, i was enable to get lein.bat > downloading by uncommenting the wget part out. One could try to move the > curl part above wget also. > > Your lein.bat file might be in \Users\name\.lein\bin\lein.bat > > I'll create an issue on github. Thanks for noticing, good luck. > > /Kevin (mobile) > On Oct 25, 2014 6:34 AM, "Geoff Caplan" wrote: > > > Hi > > > > Wanting to get Clojure running on a Win 7 machine with no diskspace for > > dual boot. It's been a demoralising experience. > > > > I tried the Win installer linked from the Leiningen website. It failed to > > download the Leiningen 1 jar - the shell simply flashed open and crashed. > > > > Dug around the git site and found a recent .bat file that's supposed to > > work with the latest Leiningen 2. Again, the shell flashed and crashed. > > > > Then manually downloaded the latest Leiningen 2 preview. Again running > > lein simply flashes and crashes the shell. > > > > There's been a recent open issue on Windows installation but it's supposed > > to be fixed. > > > > The lein.bat file is on my path and has exec permissions. I have Java 8 > > SDK installed and healthy. > > > > Not sure where I go from here - any advice much appreciated. > > > > I'm dithering between Clojure and Haskell for my next project. The Haskell > > community provide a well-maintained batteries-included Windows install for > > GHCi - I was in the Repl 60 seconds after visiting their site. I've been > > struggling with Leiningen for an hour and getting nowhere. > > > > It seems a great pity that the Clojure community seem to be ignoring those > > of us who are stuck with Windows - it must be having a negative effect on > > the uptake of the language. I see that this has been an issue for years, > > but hasn't been addressed. I'm more drawn to Clojure than to Haskell, but > > if I can't get it running I'll be forced to go elsewhere. Please help -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
+1. Two years ago we went all data driven here. We stripped the code size and complexity by a huge factor. All data encapsulation code was sent to the trash can. Our processing is driven by data more than by code. We ended up with a significant increase in generic code not linked to the business domain and the rest is made up mostly of DSLs. What a relief Luc P. > On 18 October 2014 08:28, Mark Engelberg wrote: > > > Yeah, it's hard to deny the convenience of Clojure's keyword lookups and > > standard assoc mechanism for getting and setting stored values, but I think > > Bertrand Meyer's Uniform Access Principle reflects some pretty deep > > thinking about the kinds of complications that arise in maintaining large > > programs. Although the Clojure community mostly rejects the Uniform Access > > Principle right now, as people start writing larger programs in Clojure, > > and need to maintain them for longer periods of time, it will be > > interesting to see if the pendulum swings back in favor of uniform access. > > > > You make it sound as if structuring an application around data, rather than > APIs, is untested at scale. I'd argue the opposite: the only architecture > we know works at scale is data driven. > > The largest systems we've developed, including the web itself, are data > driven. Above a certain size, they have to be, due to latency and > consistency concerns. Structuring a large system into isolated services > that communicate with data is a tried and tested architecture. > > There may be a place for the Uniform Access Principle at the medium scale, > where an application is large, but not so large it can't be hosted on one > machine. I don't think the relative merits of data-driven vs. api-driven > approaches has been proven at this scale. > > That said, I think there are reasons for betting on Clojure's approach. > Ultimately it comes down to whether we try to *manage* complexity or > *remove* complexity. The Uniform Access Principle falls in the former camp, > along with OOP and encapsulation. They're tools to manage connections > between components of a codebase. > > Clojure takes the more aggressive stance, and suggests that rather than > managing complexity, we should be focused on getting rid of it wherever > possible. For instance, where OOP languages try to manage state change > though encapsulation, Clojure just removes mutable state entirely, or at > least places it in confinement. > > Where complexity *can't* be removed, then we start to get Clojure code that > begins to look similar to OO designs. Stuart Sierra's components, for > instance, look somewhat similar to stripped-down objects. The difference in > Clojure's approach is that these constructs are a last resort, rather than > the norm. > > - James > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modelling in Clojure
Hi Phil, At some point in time after a prolonged exposure to Clojure, my mind shifted, I now think about my program flow as values, not containers being passed along. I take the problem the reverse way to find out if there's a need for a var vs a fn and state lifecyle. Here's a short summary of my reasonning: a) I just find out how long a value need to 'survive' to decide how to implement it's access and its scope. Most of the time values are ephemeral so the answer is obvious, a local binding is enough if there's a need to name it. b) If a value is required during the lifespan of the process then his scope is probably global and a var is an obvious choice. c) If a value reflects a state (as understood by clojure) that will change in time then an atom or ref can be used. Then its scope determines if it will end up in a var or not. I try to wrap a state lifecycle in a API. Most of the time leaking to the outside world involves too much refactoring, it may look simple at the beginning but you get caught in a forest fire at some point. d) I try to stay away from dynamic bindings except in rare cases (syntactic sugar for DSLs, ...). e) I do not consider Java objects as values. Their internal mutation disqualifies them to me. They seldom make it in a var in my world except when there's no other choice (database connection pool, ...). I try to confine them at the edge of the code and wrap their access in a function. If possible I try to avoid leaking them to the outside world. I try to shorten their lifespan even if it means that they will get reallocated more often. The main reason being that I want to avoid having to think about things like are they multithread safe ? To they have a finite lifecycle which prevents reuse ? They will get buried in a value as we know it in Clojure if they have to leak out. Makes it a bit harder to access them directly. If a Java object lifecycle has to leak, I wrap it in a API that relates to the application state, not to the object itself. The net result is that my code has few vars aside from the functions themselves and less state concerns. I agree that it requires some brain cells rewiring. I went along that path the first year I worked non-stop with Clojure. Luc P. > > Actually, I think that this is a real problem with Clojure, and with > data access. It is very hard to change between accessing a var as a > value and through calling a value. > > I can give two concrete examples of this. First, in my library I used a > var to store a factory object from a Java API. So I created one and > stored it in a var. This worked well, in general, but when I integrated > my library into an application, I realised that I need to get this > factory object from elsewhere -- in short I needed a function call. So I > had to change all of my `data-factory` calls to `(data-factory)`. > > Another time the same issue hit me was with Clojure's :doc metadata. > This is stored as a string, but I wanted to be able to subvert this by > calculating the string from the object containing in the var. As far as > I can tell, this is impossible in Clojure without changing all the > client code that accesses the :doc metadata. > > Java does not have this problem by common design patterns -- fields are > declared private and always accessed through a function. If I understand > things correctly, Scala avoids the problem in the same way, although it > autocodes the accessors for you, so avoids the boilerplate. > > In Clojure, it seems the only way to avoid this would to wrap up values > in `constantly` and access everything as a function. > > Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Préfontaine 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
Re: Profiling in Counterclockwise
As far as I know the external tools exposed so far are the only way to get the breakdown you are seeking. Profiling in dev with an external tool is kind of a conflicting goal to me. Such tools used in dev are also a form of micro benchmarking on incomplete code. Your app is not fully packaged, how meaningful are the hot spots you may find at this stage ? What does it tell you about the future behaviour of your app ? With the REPL in the way reevaluating code as you modify it ? Criterium allows us to evaluate at any level in our code if the performance is acceptable or not. It does a sane job collecting stats. I can exercise 5% or 50% of the code and get stats from its execution within a couple of minutes with the workload size I desire. I can do minute changes and see the effect. If the performance is satisfactory, no need to dig for a hot spot at this stage. We look at hotspots when the app packaging is near completed in test. Then its behaviour is much closer to production. But we rarely find a performance issue justifying a code change except if it's trivial. It's a matter of putting some reasonable effort toward optimization when justified. Doing this early in dev with a time efficient tool to me is a better use of my time than using a sophisticated one requiring some complex wiring from my part. Luc P. > On Sunday, October 5, 2014 4:58:04 PM UTC-4, Luc wrote: > > > > Have a look at criterium. > > > > https://github.com/hugoduncan/criterium > > > > That's (micro)benchmarking, not profiling. Profiling would break down the > time spent in different functions and help to identify hot spots that might > especially benefit from optimization. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Profiling in Counterclockwise
Have a look at criterium. https://github.com/hugoduncan/criterium It will allow you to look at the performance of code chunks in the REPL, you get meaningful results and a solid comparison basis. So practical that it's part of my default profile. You can test different approaches w/o leaving the REPL. I use VisualVM and similar tools for integrated tests once the app is packaged as a safeguard. Luc P. > On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote: > > > > When I need to profile (which is asmittedly quite rare), I use VisualVM, > > which should have been installed along with the JDK. I'd recommend editing > > the default settings to remove clojure.** and add your own namespaces as > > starting points for the profiling. > > > > For more lightweight approaches, I'd suggest checking out Timbre and > > Criterium, though I have very little experience with both. > > > > > > None of this is Eclipse specific or runs in Eclipse. > > > > So, what you're saying is that I'd have to > > 1) Package everything up > 2) Deploy to somewhere > 3) Learn how to use classpath configuration and stuff> > 4) Identify hot spots > 5) Make improvement of some sort > 6) Back to step 1? > > Because that seems to *completely eliminate* the benefit of having a REPL > and fast development/try things/edit cycle. :( > > Meanwhile, why did I get google results for a supposed "Profiling and > Logging perspective" in Eclipse if no such thing exists? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha2
The keyword has different meaning depending on the language and context. Most of the time to prevent optimizations by the compiler to insure write ordering and some consistent view (Java use). Not here. It's meant to warn that nothing is guaranteed, no synchronization, no consistent view. It should be kept local (no leak outside of a narrow scope) and certainly not shared by multiple threads. Luc P. > Excuse my ignorance but does "volatile!" have anything to do with Java's > "volatile" keyword? Is there any relation at all? I'm not suggesting a name > change, but it can be confusing coming from that angle. Maybe a blurb in > the doc string? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha2
+1 for the ! No atomic changes here, no coordination whatsoever. At the mercy of the caller... > I asked Rich and he said "making a volatile is as dangerous as any ! op". > > Some people have also asked about vswap! being a macro instead of a method > on Volatile. The issue there is that vswap! takes a variadic number of > update function args. If implemented as a method, you'd need to provide > multiple arities or eventually use apply (like in Atom's swap! > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Atom.java#L79) > - doing it in a macro lets that expansion take place at compile time to > provide better performance without the apply. > > > > > > On Mon, Sep 8, 2014 at 1:36 PM, Jozef Wagner wrote: > > > FYI the ticket about volatile is at > > http://dev.clojure.org/jira/browse/CLJ-1512 and the same question was > > raised there. > > > > On Mon, Sep 8, 2014 at 4:25 PM, Frantisek Sodomka > > wrote: > > > Hello, > > > I posted a question about volatiles on the github commit: > > > > > https://github.com/clojure/clojure/commit/60440977823752f13a3fec3637538e9a1d68c5d4 > > > > > > I don't know if anybody noticed, so... why is volatile created with > > function > > > "volatile!" and not "volatile" ? Atoms, refs and agents don't have > > > exclamation mark in their constructor functions. > > > > > > Should I think about volatiles as mutable locals? :-) > > > > > > František > > > > > > > > > On Friday, September 5, 2014 4:26:53 PM UTC+2, Alex Miller wrote: > > >> > > >> Clojure 1.7.0-alpha1 is now available. > > >> > > >> Try it via > > >> - Download: > > >> http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/ > > >> - Download securely: > > >> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/ > > >> - Leiningen: [org.clojure/clojure "1.7.0-alpha2"] > > >> > > >> Highlights below, full change log here: > > >> https://github.com/clojure/clojure/blob/master/changes.md > > >> > > >> For users of Clojure 1.7.0-alpha1, there have been a few important > > changes > > >> in transducers since alpha1: > > >> - Removed flatmap transducer > > >> - Added cat transducer > > >> - mapcat 1-arity is now a transducer, specifically: (comp (map f) cat) > > >> - The completing function has been lifted to be public > > >> > > >> Clojure 1.7.0-alpha2 has the changes below from 1.6.0: > > >> > > >> ## 1 New and Improved Features > > >> > > >> ### 1.1 Transducers > > >> > > >> Transducers is a new way to decouple algorithmic transformations from > > >> their > > >> application in different contexts. Transducers are functions that > > >> transform > > >> reducing functions to build up a "recipe" for transformation. > > >> > > >> Also see: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > >> > > >> Many existing sequence functions now have a new arity (one fewer > > argument > > >> than before). This arity will return a transducer that represents the > > same > > >> logic but is independent of lazy sequence processing. Functions included > > >> are: > > >> > > >> * conj (conjs to []) > > >> * map > > >> * mapcat > > >> * filter > > >> * remove > > >> * take > > >> * take-while > > >> * drop > > >> * drop-while > > >> * cycle > > >> * take-nth > > >> * replace > > >> * partition-by > > >> * partition-all > > >> * keep > > >> * keep-indexed > > >> > > >> Additionally some new transducer functions have been added: > > >> > > >> * cat - concatenates the contents of each input > > >> * de-dupe - removes consecutive duplicated values > > >> * random-sample - returns items from coll with random probability > > >> > > >> And this function can be used to make completing transforms: > > >> > > >> * completing > > >> > > >> There are also several new or modified functions that can be used to > > apply > > >> transducers in different ways: > > >> > > >> * sequence - takes a transformation and a coll and produces a lazy seq > > >> * transduce - reduce with a transformation (eager) > > >> * iteration - returns an iterable/seqable/reducible seq of applications > > of > > >> the transducer to items in coll. Applications are re-performed with > > every > > >> iterator/seq/reduce. > > >> * run! - run the transformation for side effects on the collection > > >> > > >> There have been a number of internal changes to support transducers: > > >> > > >> * volatiles - there are a new set of functions (volatile!, vswap!, > > >> vreset!, volatile?) to create and use volatile "boxes" to hold state in > > >> stateful transducers. Volatiles are faster than atoms but give up > > atomicity > > >> guarantees so should only be used with thread isolation. > > >> * array iterators - added support for iterators over arrays > > >> > > >> Some issues created and addressed during development: > > >> * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511) > > >> * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497) > > >> > > >> ### 1.2 Keyword and Symbol Construction > > >> > > >> In r
Re: Useless Java error messages
Where do you see a Java error here ? I see the Clojure implementation reporting that you are trying to apply a numeric operator to a null/nil value :) I agree the JVM stack traces are not nice and polluted by all the frames which may/may not be relevant. The messages are not always as clear as this one either. You do not have any source file line number anywhere in the stack trace pointing to your code ? Luc P. > Compiling a file in Emacs, this error: > > "NullPointerException clojure.lang.Numbers.ops (Numbers.java:961)" > > . leaves me clueless as to where the error occurred. > > Is there hope for native Clojure debugging anytime soon as this is the > kind of thing which can easily drive a non-Java user like me to > distraction? I noticed the Elixir community had the same problem with > Erlang's cryptic error messages and produced their own error logging to > make the language attractive to non-Erlangers. This seems to me to be > perhaps the biggest barrier to entry with hosted languages. We can't > expect everyone coming to Clojure to master Java's less-than-helpful > error messages. Many will just give up. > > gvim > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is Clojure a language for growth?
+1 same weakness + big fingers on small iPhone keyboard :( Urgent need for a second one... We choose Clojure in 2008 strictly for efficiency. In 2009 after being in prod, we were told that hiring would be a major problem. We dealt with this noise by accepting the fact that we will train people. Why ? Because we need 7 to 10 times less people. Everything got simpler from design to deployment. We get people to learn by adding tests. I can't stand TDD but I agree that safeguards like automated tests add value. So let the newcomers do the boring stuff while they learn :) I think that there is a huge perception problem. For some reason apparently in the industry complex systems = huge teams. It looks to me more like a peeing contest more than anything else. My team is bigger than yours, blablabla, Like if bigger meant better To me big teams are mostly a sign of inefficiency except if you intend to send men on the moon or similar unusual goals. Luc P. > + Grammar. I should not write correspondence before having coffee. > > On Thursday, August 21, 2014 9:31:42 AM UTC+2, Henrik Eneroth wrote: > > > > Sweden has some things going for it, and some not, as always. I think > > business overall is somewhat less cutthroat here than in the States, which > > is why it struck me that I might be making assumptions about what OP should > > or should not do out of ignorance of his situation. The scape goat > > reasoning really brought this home. > > > > At the two most recent places I've been (I'm a consultant, a UX designer), > > they've worked with autonomous teams. That is, the teams are themselves > > responsible for deciding how to solve a problem, sometimes including what > > programming language to use. One result of this seems to emerge (I only > > have a sample size of two) a microservice centered design and a general > > decoupling between the teams. > > > > Also, it naturally seems to lead to a more heterogeneous environment, for > > good or for bad. This seems to be somewhat self-regulating however, as > > other most members of a team will protest if one member wants to write the > > new service in the Shakespearean Programming Language, for example. It also > > leads to the same kind of resistance to more sensible choices as well, like > > Clojure. But unlike SPL or Brainfuck, they actually have chance of being > > used if they show merit, probably by filling some niche role to begin with. > > > > When I was with Spotify, I learned that they had snuck in some Clojure in > > one of the teams of the organization. No one has been fired yet, and > > everyone seems happy enough. Especially the people who now get to do at > > least *some* Clojure during their work day. > > > > Oh, and like Linus, I try to promote Clojure wherever I go. As a designer, > > I'd love to work with a team that uses Clojure. That is, a team that > > understands that incidental complexity eventually seeps out to for the user > > to deal with, and so on. Unfortunately, being framed as a designer means I > > have less natural authority when I say that Clojure is awesome. Although > > this is somewhat mitigated somewhat by the sheer shock of having a designer > > saying something comprehensible about a programming language. > > > > On Thursday, August 21, 2014 7:44:18 AM UTC+2, Quzanti wrote: > >> > >> "If an investor were kicking people out, its usually because money is > >> running low or for other more diffuse reasons. If an investor or boss > >> somewhere where kicking out people at random, he would quickly loose > >> respect from his other employeers. The rest would soon leave as well" > >> > >> Hence the need for a scapegoat. Generally if an investor can make 20% of > >> their startups work, people will blame the technologists for the failure > >> of > >> the other 80%, and the investor will have a PR machine to distort the > >> history if needed. But yes, startup hubs work best when there are angel > >> investors who want to build a personal reputation or where the > >> institutional investors have strong links with the universities producing > >> the start up talent and so don't want to jeopardise those (eg the Stanford > >> University system). Even the best VCs will shut down the majority of their > >> start ups though, so you'd think that would make people avoid them, but > >> there are always people out there who need money to try and realise their > >> dreams. > >> > >> All a bit tangential to the the original thread question th
Re: CLJS Function clobbering js function of same name
That's what I inferred but it has nothing to do with my astonishing ESP capabilities, currently drinking an excellent beer in Rabat :) Cheers, Luc P > I meant would not > > > On Mon, Aug 4, 2014 at 4:28 PM, David Nolen wrote: > > > I would rely on the behavior in the REPL to check this - the REPL > > compilation environment is likely different. > > > > > > On Mon, Aug 4, 2014 at 3:59 PM, Sam Ritchie wrote: > > > >> Hey Herwig, > >> > >> I'm currently on [org.clojure/clojurescript "0.0-2261"], and I'm seeing > >> no munging: > >> > >> paddleguru.api.register.validation> (defn console []) > >> # >> }> > >> nil > >> paddleguru.api.register.validation> (defn console [s] (.log js/console s)) > >> # >> }> > >> nil > >> paddleguru.api.register.validation> (console "HI!") > >> "Error evaluating:" (console "HI!") :as > >> "paddleguru.api.register.validation.console.call(null,\"HI!\");\n" > >> # > >> > >> TypeError: undefined is not a function > >> at console (eval at ( > >> https://local.paddleguru.com/cljs/dev/generated.js:83183:294), > >> :1:146) > >> at eval (eval at ( > >> https://local.paddleguru.com/cljs/dev/generated.js:83183:294), > >> :1:108) > >> at eval (eval at ( > >> https://local.paddleguru.com/cljs/dev/generated.js:83183:294), > >> :5:3) > >> at https://local.paddleguru.com/cljs/dev/generated.js:83183:289 > >> at https://local.paddleguru.com/cljs/dev/generated.js:83197:4 > >> at G__30641__2 ( > >> https://local.paddleguru.com/cljs/dev/generated.js:23732:22) > >> at G__30641 [as call] ( > >> https://local.paddleguru.com/cljs/dev/generated.js:23977:28) > >> at null. ( > >> https://local.paddleguru.com/cljs/dev/generated.js:83238:80) > >> at goog.events.EventTarget.fireListeners ( > >> https://local.paddleguru.com/cljs/dev/generated.js:42772:23) > >> at Function.goog.events.EventTarget.dispatchEventInternal_ ( > >> https://local.paddleguru.com/cljs/dev/generated.js:42817:26) > >> nil > >> > >> Herwig Hochleitner > >> August 4, 2014 at 11:43 AM > >> Thomas, in my test, (defn console []) is munged aswell, so I'm guessing > >> that Sam is using a version from before > >> https://github.com/clojure/clojurescript/commit/f371c04d95a00cdda79c63f89f35088d62de8e73 > >> Sam, is that correct? > >> > >> The observation that eval should be in js-globals is irrelevant, because > >> as I detailed a couple of messages ago, js-globals is wrong and should be > >> removed. > >> (fn x []) should never cast a shadow on js/x for any x. > >> So far, I believe David to agree. I commented on CLJS-833 to reflect this > >> point of view. > >> > >> Waiting on a statement towards fully removing gensyms from the compiler, > >> i.e. CLJS-401 revisited ... > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to the Google Groups > >> "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > >> Thomas Heller > >> August 4, 2014 at 10:40 AM > >> https://gist.github.com/thheller/4731f682665d38b1053c > >> > >> On Monday, August 4, 2014 3:34:33 PM UTC+2, Nicola Mometto wrote: -- > >> 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
Re: Scheduling state change?
Oups typo in my last reply should be (fn [] ) IPhone quirk, tiny, very tiny keyboard... Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure Contributor Agreement process update
What about the real world constraints ? As far as I know, everyone needs air, water, heat, and a minimal food ration to survive. The day I cut your air away, I bet you'll be suddenly be very concerned about the 'the physical world' and that you will relinquish the 'digital age' way back in some remote primitive place in your brain :) Ok, lawyers are not as vital as air, however they flourish on litigation systems like some plants in dump yards. The day you are stuck in a lawsuit or the day someone steals something you have created and you have not cared about these 'real' things you are left alone on an ice bank, plenty of air I agree but seldom provided with a grocery store and a Starbuck... Contrary to popular belief, sharing does not imply that you allow others to steal your ideas so they can make $ out of them or claim that it's now their own and that you should get lost. I hope you stay anchored in the real world :))) Luc P. > Sorry if that was already answered, > > Is there a possibility to get rid of this legalwall? > > I realize that there are good intents behind the existing practice, but it > feels a bit wrong for an open source artifact in the digital age of instant > sharing. > > > > > Starting today, we have updated the Clojure Contributor Agreement > >> process. > >> > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
I maintain that the average human being looking at sed commands would rather end up standing on his head for a significant amount of time to avoid it :))) BTWY, I have been scripting under u*x for a few decades by now. I resort to it when nothing and I mean nothing (think about Daffy Duck's voice here) else can do it :)) Luc P. Luc P. > > > On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: > > > > ... Then I add the new functions to the declare statement by hand, or I > > periodically do something like: > > > > grep defn mysourcefile.clj >> mysourcefile.clj > > (Be careful to use two ">"s!) > > > > and then I edit the junk at the end of the file into a declare statement > > at the top of the file. And maybe if f I were ... lazier, I'd code a > > script that would update the declare in one pass. > > > > OK, I couldn't resist my own implicit challenge. > > #!/bin/sh > sourcefile="$1" > newsourcefile="new.$sourcefile" > > newdeclare=$(echo '(declare' \ > `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` ')' \ > | sed 's/ )/)/') > > sed "s/(declare .*/$newdeclare/" "$sourcefile" > "$newsourcefile" > > This writes a new version of the file named new.. Or if you > either trust your script or trust your backups, and are on a system that > includes the mighty ed <http://www.gnu.org/fun/jokes/ed.msg.html> editor, > you can replace the last line with: > > echo "1,\$s/(declare .*/$newdeclare/\nw\n" | ed "$sourcefile" > > which edits the file in place, assuming that the previous version of the > declaration was on one line. You may want to use a different scriptable > editor. > > The messy part is the sed and tr line: > > `sed -n '/defn/s/(defn-* //p' "$sourcefile" | tr '\n' ' '` > > The sed part finds all of the lines with "defn" in them, then substitutes > the empty string for "(defn" or "(defn-". 'tr' then removes the newlines > between the function names, replacing the newlines with spaces. You'll > need something a little more complicated if you put the parameter vector or > anything else on the same line as the function name. The 'echo' on the > previous line, along with the final ')' adds "(declare" and its closing > parenthesis. Those two lines can be used by themselves to generate a > declare statement from the command line. The 'sed' command after these > lines isn't necessary; it just removes an unnecessary space before the > closing parenthesis. > > Obviously, there will be source files on which this won't work. It's not > worth making it foolproof. > > It's a certainty that others would code this more elegantly or more > succinctly. It could be written in Clojure, obviously, but still wouldn't > be foolproof unless someone hacks it from the Clojure parser. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Top-down code in namspaces
Yeah, it's certainly hard, just tried it,
blood pressure increases in the head
and my eyes were bulging out of their
sockets.
A bit easier using these chairs
that allow you to flip upside
down, less strain on the neck and
no need to keep up your
balance every second or so.
My apology to the readers of the
above lines, I could not resist :)))
Luc P.
> It takes a while (a couple months) to get used to reading things
> upside-down, but I wouldn't want to go back. Knowing with certainty that
> some called method is defined above in the compilation strategy simplifies
> code-reading and comprehension by minimizing where you have to look, and it
> also makes it easier to move stuff around with a text editor than what I
> imagine the alternative would provide.
>
> I haven't used a late-binding lisp in a large code-base, so I'm contrasting
> against my experience with Java.
>
>
>
>
> On Tue, Jun 3, 2014 at 10:51 AM, Phillip Lord
> wrote:
>
> > Gregg Reynolds writes:
> >
> > > 4. Put your helper funcs ("defn-" stuff) in helpers.clj, without a call
> > to
> > > ns at the top, then (load "helpers") at the top of the file that uses
> > them.
> > > You still get the effect you're looking for, with a one line "preface"
> > > that tells the reader where to look for more info. Seems to work in a
> > > little test app (lein new app topdown):
> >
> > This is not side-effect free (sorry for pun). I did this for my code,
> > and now slamhound doesn't work on it. Other tools too? I don't know.
> >
> >
> > https://github.com/technomancy/slamhound/issues/61
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Luc Prefontaine sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
