Re: Why You Should NOT Implement Layered Architecture
I did not imply that OO was absolutely bad. It's what people are doing with it. It's been a plague for the last 10 years. The rope is long and thick, more than enough to hang yourself in several reincarnations. As far as using OO to represent the real world, it's a mistake. Things are not as straight forward as they look like. Modeling the surface is most of the time wrong not withstanding the time it can take to model everything you can see because you did not think about the essential stuff you will really need to solve the problem at hand. I saw enough insane models were the business "model" was so utterly complex that it made any system improvement a Titan task. Generality gets hit badly in many OO designs. You can build an 8 mille bridge with Lego bricks but it's not optimal. There are better ways. We are not ants or termites. Luc P. > Relevant? Well it is always nice to find different articles that are > bashing on the issues that could appear from badly designed OO programs if > you want to get Clojure into consideration in your organization. > > I don't support that OO is bad. It is just complicate to constrain yourself > from making it overcomplicated because after all they teach us that it > should be representation of the real world and sometimes the world is scary > and crazy place... > > > > > > Best regards | Med venlig hilsen, > > KALINA TODOROVA > T: 0045 52 64 93 73 > E: ad...@ki6i.com > > Frederikssundsvej 194 2 1 > 2700 Brønshøj > <http://www.facebook.com/ki6i.kali> <http://dk.linkedin.com/in/ki6i90> > <https://twitter.com/#%21/ki6i> <http://blog.ki6i.com> > > On Sun, Sep 14, 2014 at 8:01 PM, Softaddicts > wrote: > > > I think this article is partly true, at least in the OO world we know > > today. > > > > I dealt with a number of OO based commercial softwares in the past 10 years > > that used abstractions that were at best annoying, at worse made the > > internals > > obscure up to a point where you wondered if these were added only to insure > > some job security to the "experienced" anarchitects that created them -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why You Should NOT Implement Layered Architecture
I think this article is partly true, at least in the OO world we know today. I dealt with a number of OO based commercial softwares in the past 10 years that used abstractions that were at best annoying, at worse made the internals obscure up to a point where you wondered if these were added only to insure some job security to the "experienced" anarchitects that created them. Their implementations did not do anything to make things clearer either. Frameworks are also part of the problem. They tend to inflate up to a point were there initial intent is not even obvious these days. Remember why Spring came to life ? Look at it today... it tries to be everything. These days I stay away from frameworks and I my work life is far more simple. My personal rule is that if you create or use abstractions not related to your business model, you should question yourself seriously if you need them. The "bottom stuff", Clojure current abstractions coupled with a few others, message queues, configuration management, ... is a toolbox allowing you to grab the moon. It's more than enough to do a lot of milleage. Luc P. > Looks like a pretty standard rather naif article by someone who knows > enough to be dangerous but not enough to actually understand about > trade-offs. > > And I'm not sure why you think it's even slightly relevant to Clojure: or > did you think Clojure eschewed abstractions? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lein feature to check for updates in dependencies?
lein-ancient plug in Luc P. > I thought for sure I saw this feature, but I can't find it. > > Isn't there a way to scan for possible updates to dependencies in a project? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
I thereby promise to not use my mobile phone ever again to access github :) Luc P. > Oops, I skipped the volatile keyword while reading the code snippet. > Sorry :) > > Luc P. > > > > > No, it means exactly the same thing as volatile in Java (and is implemented > > in the Volatile Java class which holds a single volatile field). Basically > > a "volatile box" since a field must exist inside a class. The semantics are > > the same as Java - writes are guaranteed to be seen by subsequent reads on > > any thread (that property is not guaranteed by a non-volatile field). > > > > vswap! on a volatile is syntactically similar to swap! on an atom but > > without the atomicity guarantees. That is, vswap! consists of a read > > followed by a write but this is non-transactional so another thread could > > change the value in between. In other words: don't use this unless you can > > enforce thread isolation or safety through other means. Thus, volatiles are > > dangerous *by default*, unlike every other stateful thing in Clojure. > > > > Some stateful transducers use volatiles for performance and provide thread > > isolation via how they are constructed and used. > > > > > > > > On Tuesday, September 9, 2014 12:06:36 PM UTC-5, Luc wrote: > > > > > > 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 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. > > > > > > > -- > > > 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. > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group,
Re: [ANN] Clojure 1.7.0-alpha2
Oops, I skipped the volatile keyword while reading the code snippet. Sorry :) Luc P. > No, it means exactly the same thing as volatile in Java (and is implemented > in the Volatile Java class which holds a single volatile field). Basically > a "volatile box" since a field must exist inside a class. The semantics are > the same as Java - writes are guaranteed to be seen by subsequent reads on > any thread (that property is not guaranteed by a non-volatile field). > > vswap! on a volatile is syntactically similar to swap! on an atom but > without the atomicity guarantees. That is, vswap! consists of a read > followed by a write but this is non-transactional so another thread could > change the value in between. In other words: don't use this unless you can > enforce thread isolation or safety through other means. Thus, volatiles are > dangerous *by default*, unlike every other stateful thing in Clojure. > > Some stateful transducers use volatiles for performance and provide thread > isolation via how they are constructed and used. > > > > On Tuesday, September 9, 2014 12:06:36 PM UTC-5, Luc wrote: > > > > 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 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. > > > > > -- > > 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Useless Java error messages
Ah ! Emacs, an old friend that I should eventually revisit after 30 years... Long time no see :) Luc P. > On 01/09/2014 17:50, Luc Prefontaine wrote: > > 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. > > > > Sorry, I was a bit trigger-happy with this one. Turns out it was Emacs > cider truncating the stack trace to a single line. Someone on IRC > pointed me to `(pst)` within Emacs cider which displays the full stack > trace. > > 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 happening in this code?
Repeat several times the magic incantation, dynamic, dynamic, dynamic, :))) Your second definition overrides the first one. Generating a warning when a redefinition occurs appears to me as not practical. In the REPL, you would not like it at all. Add another top level var to enable/disable this 'feature' ? That most people would disable anyway ? Warn when loaded from a file ? Maybe. But the compiler would have to be aware of this context. What about reloading a name space from a file in the REPL then ? Oups... Too much trouble IMHO. Luc P. > I am new to Clojure, I am currently at Beginner level. While trying to run > small programs, I found that I can load a file having duplicate code. Let > me explain it with example. > > This is the code > > (ns clojure_begins_19_08_2014.core) > > (defn first-fn[x] > (print x)) > > (defn first-fn[x] > (print "Value of x with String " x)) > > (first-fn 10) > > See, above code consists of two function with same name and with same > number of arguments. > When I call first-fn, the function declared later gets called. I get output > as: > > Value of x with String 10 > nil > > So can any one explain how this thing is happening and also explain how we > can have same function written 2 times in a same namespace. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Scheduling state change?
you want to pass a closure, not call my-func recursively: (defn my-func [id] (println id ) (.schedule executor #(my-func (inc id)) 1 TimeUnit/SECONDS)) or (defn my-func [id] (println id ) (.schedule executor (fn [_] (my-func (inc id))) 1 TimeUnit/SECONDS)) Luc P. > > > > > Hi, > > > > I gave this a try over the weekend and then I do this it all works fine: > > (import java.util.concurrent.ScheduledThreadPoolExecutor ) > (import java.util.concurrent.TimeUnit) > (def executor (ScheduledThreadPoolExecutor. 1)) > > (defn my-func [] > (println "adsf" ) > (.schedule executor my-func 1 TimeUnit/SECONDS)) > > That prints out the line once a second, every second. But when I change my > function so that it takes arguments, like this: > > (defn my-func [id] > (println id ) > (.schedule executor (my-func (inc id)) 1 TimeUnit/SECONDS)) > > I get a stackoverflow and the print out happen immediately, they are not > scheduled. This is also the behaviour I got with the at-at library. I'd > rather use something like the latter as it stops me from having mutable > state inside my functions. > > Any ideas? > > Thomas > > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: When to use ! in function name
You do not reuse log file output to propagate state changes. If you do I would like to know for what purpose... In my world the ultimate goal of log file output is human consumption with or without aggregation or alert filtering. It has nothing to do with your system internal state. It's merely a reflection of what changed at best. Luc P. > 2014-07-11 14:19 GMT+02:00 Softaddicts : > > > I look at side effects this way, will it ever record some state change > > that some > > code in the universe will eventually rely on ? > > > > If no, then there's no state change/side effect to care about. > > > > Sending a message is a side effect (a pgm will eventually use it), writing > > to > > a database, ... qualify. > > > > Then writing to a log file should qualify also. And as I understand it, it > does not. > > -- > Cecil Westerhof > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: When to use ! in function name
I look at side effects this way, will it ever record some state change that some code in the universe will eventually rely on ? If no, then there's no state change/side effect to care about. Sending a message is a side effect (a pgm will eventually use it), writing to a database, ... qualify. Changing a screen output which has no long term memory of what is written to it and is meant to communicate with carbon entities is not to me a side effect. A GUI to me is merely a way to present some state information, not a state by itself. It can always be constructed back again. So unless we evolve to some silicon dice life form, this rule helps me segregate what is a side effect from a code standpoint :) That may help, Luc P. > 2014-07-10 19:10 GMT+02:00 Softaddicts : > > > The fn that does the display is the one having side effects. > > Now if your look fn creates the side effect, it should reflect that in its > > name. > > > > Look discribes the current location. So it has a side-effect, but as I > understood from others it is not about side-effects, but global state. That > does not change, so I should not use the '!'. > > > > > > But... I wonder why it does so. Looking at something does not change state. > > > > No, it does not change state, but it prints the description. So it has a > side effect. It is not pure, but it is idempotent. > > -- > Cecil Westerhof > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: When to use ! in function name
The fn that does the display is the one having side effects. Now if your look fn creates the side effect, it should reflect that in its name. But... I wonder why it does so. Looking at something does not change state. You may be better splitting the side effect away from it or change the name. Looks (no pun intended) odd from a naming perspective but w/o looking at your code base it's hard to telll. It may made sense in your context. If look is a predicate, the name might not be appropriate. number? is clearly a predicate. "look" does "look" as a true/false property to me. visible? or hidden? look to me as a predicates. But again it may make sense in your context. If your fn does too many things, you may want to split it. Luc P. > When a function returns a true/false value you should end it with a '?'. > > Clojure Programming says that with side effects you should end the function > name with a '!'. > > I have functions reset-game! and walk!. But what about a function like > look? It does not change state, but it displays where you are. So it has a > side effect. But most of my functions have this. So, should I append them > all with a '!'? > > -- > Cecil Westerhof > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: System/getenv can't read env vars?
And did you test this by setting it from .bashrc ? > If I call: > > (System/getenv "MY_VAR") ;=> nil > > From bash > > set | grep MY_VAR ;=> foo > > echo $MY_VAR' ;=> foo > > I can do this from bash, as well as my tmux session. I use tmuxinator to > launch a repl and vim, thus my repl process is running inside TMUX. That > said, I can see the env var in other tmux sessions. > > Anyone ever run across this issue? Am I doing something wrong? The point > of this was to 12 Factor App-ify my environment for setting various runtime > config options. Is there another/better way to do the same thing that > others prefer. > > Thanks, > > Jarrod > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: System/getenv can't read env vars?
I assume you did export MY_VAR before starting you REPL ? Luc P. > If I call: > > (System/getenv "MY_VAR") ;=> nil > > From bash > > set | grep MY_VAR ;=> foo > > echo $MY_VAR' ;=> foo > > I can do this from bash, as well as my tmux session. I use tmuxinator to > launch a repl and vim, thus my repl process is running inside TMUX. That > said, I can see the env var in other tmux sessions. > > Anyone ever run across this issue? Am I doing something wrong? The point > of this was to 12 Factor App-ify my environment for setting various runtime > config options. Is there another/better way to do the same thing that > others prefer. > > Thanks, > > Jarrod > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: OT: Github Alternatives
Agree, we have been using git with private repos in gitolite or gitosis for several years using cmd line or Eclipse egit. Git by itself is very flexible and well designed. A huge improvement over SVN which we were using before. I need a cheat sheet to track the not so common stuff done via cmd line but this is the only thing I can criticize about git. Or it's my bad memory that can't seem to record them :) Just installed gitlab community edition yesterday and loaded our repos in it. That's nice to have a cute GUI on top of git. This will get around most of this cmd line "weakness" and repo management will be easier. Luc P. > In my opinion, saying "I have problems with it, then, it is bad" is very > bad argument. I'm not defending git, I'm only criticizing your arguments. > The only way to save money and pain, is knowing well the tools that you are > using. And git doesn't make any magic. > > ;) > Andrey > > > > 2014-07-01 15:23 GMT+02:00 Charles Harvey III : > > > That is truly sad if Bzr dies out. I have had such horrible experiences > > with Git that I still can't understand what people like about it. Well, > > aside from the fact that it is not SVN and that there is github. > > > > > > > > > > > > On Tuesday, July 1, 2014 6:58:32 AM UTC-4, Thorsten Jolitz wrote: > >> > >> Charles Harvey III writes: > >> > >> > You could abandon Git and save yourself a lot of money and pain. > >> > > >> > Start using Bazaar! http://bzrinit.com/ > >> > (http://bazaar.canonical.com/en/) > >> > > >> > "Hosting" is seriously you setting up an ftp server (sftp, ssh, scp) - > >> > whatever. There is web viewer plugin: > >> > https://launchpad.net/loggerhead. it is basically an apache module -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: lein dependcies and exclusions
We always use a separate profile to package stuff for delivery. And of course we never refer to these profiles in the global lein config. >From the pom it seems it's not brought in by one of the top level dependencies. Did you check the output of lein deps :tree ? It's a bit more obvious to find if an unwanted dependency comes from one of the explicit ones you specified. I suggest creating a separate profile and invoke your action with the with-profile option. This way you can clear dev-dependencies and be in control or the dependencies w/o interference from your dev environment setup. Luc P. > Softaddicts writes: > > You are using swank aren't you ? > > No, not as far as I can tell. Being using nrepl for a long time. > > > This is the completion library it uses. Check your lein default profile. > > Maybe you requiring it there. > > As I said, I've removed by profile.clj for this test. Now, maybe I have > done this wrong, of course. If you get a different result, it certainly > suggests it. > > > > If you want to avoid this being included, create a lein profile like > > prod or deploy and respecify your dependencies explicitly. > > I am more worried about tools.nrepl NOT being included. This is breaking > my application. > > 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: lein dependcies and exclusions
You are using swank aren't you ?
This is the completion library it uses. Check your lein default profile.
Maybe you requiring it there.
If you want to avoid this being included, create a lein profile like
prod or deploy and respecify your dependencies explicitly.
Use it then to package your target.
Luc P.
>
>
> I'm struggling a little with dependencies in lein for an artifact that
> is a dependency of a maven project. I have the following test sample
> working.
>
> This is project.clj
>
>
> (defproject test-exclusion "0.1.0-SNAPSHOT"
> :description "FIXME: write description"
> :url "http://example.com/FIXME";
> :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
> :dependencies [[org.clojure/clojure "1.6.0"]
> [org.clojure/tools.nrepl "0.2.3"]])
>
>
>
> lein deps :tree
>
> [clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]]
> [org.clojure/clojure "1.6.0"]
> [org.clojure/tools.nrepl "0.2.3" :exclusions [[org.clojure/clojure]]]
>
> I don't understand where clojure-complete has come from here -- I've
> disabled profile.clj for the test so it's not that. Otherwise, the
> exclusions seem reasonable -- tools.nrepl specifies 1.2.0.
>
> This generates the folling pom (which is what is used when maven starts).
>
>
>
>
> org.clojure
> clojure
> 1.6.0
>
>
> org.clojure
> tools.nrepl
> 0.2.3
>
>
> org.clojure
> tools.nrepl
> 0.2.3
>
>
> org.clojure
> clojure
>
>
> test
>
>
> clojure-complete
> clojure-complete
> 0.2.3
>
>
> org.clojure
> clojure
>
>
> test
>
>
>
>
> Both clojure-complete and tools.nrepl appear twice, the second time in
> test scope with an exclusion. In many hands, this the second version
> wins. A downstream project which depends on this project will not
> include tools.nrepl as we are outside the test scope; this is breaking
> my application.
>
> Have I messed up?
>
> 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.
>
--
Softaddicts sent by ibisMail from my ipad!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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
se be patient with > > your first post. > > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: non-lazy clojure?
.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: help with the lawyers?
g Clojure on back end- lawyers > reviewing EPL had objections. Would appreciate any advice on how to deal > with them. > > Again- web site, not distributing or modifying Clojure. I have no expertise > with Open Source Licenses or lawyer-ese jargon. > > These are the specific objections- do they even apply in the context of web > services? > > 1. "This Agreement is governed by the laws of the State of New York". Not > acceptable: The federal government cannot agree to be bound by state law. > > 2. "Each party waives its rights to a jury trial in any > resulting litigation". Not acceptable: Only DOJ can control litigation. > > > 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 compiletime vs runtime
Ahem :) a) The fn x does not exist in the universe until you call foo, hence you cannot expect the compiler to known anything about it if it's not called before making any reference to x. b) If you refer to x at the top level (the "universe" above :) before defining it, obviously it does not exist. You might use (declare x) before referring to it. This allows you to define it later at your convenience. c) In general, you should avoid using def/defn within a function. Macros may do that but this is a different story. d) Yes code at the top level is executed, how can you expect the REPL to work interactively if forms are not evaluated first ? A defn expands to a function call, a special form in fact but it still behaves like a function. Any function call at top level will get executed after being compiled to byte code. Now about the "compilation" step... Traditionally, most Lisps allow you to refer to stuff in interpreted mode not defined yet hoping that it will get defined by the time you run the code that refers to these undefined things. It can even be something transient on the stack... oups... You can still compile in other Lisps but this is a special case where you have to make sure that stuff is defined in some way. You need to add directives to tell the compiler that this stuff will exist later and that it can safely refer to it. On the JVM, some underlying byte code has to be generated for any forms typed in the REPL at the top level any reference has to be defined before hand. There's no other way to generate byte code... there cannot be black holes waiting to get filled later. Hence the "compilation" phase and the restriction that stuff you refer to are to be defined either directly or using declare. Hope it explains the compromise. Luc P. > Is there an explanation of how clojure deals with scoping and its static > checking. It seems to be a hybrid of a static language and a dynamic > language when it comes to compilation. I'll elaborate. > > The following code wont compile: > (defn x [] nil) > (defn y[]) ((x)) > > however this code will compile: > > (defn foo[] (defn x[] nil)) > (defn y[]) ((x)) > > but calling y before foo fails with a runtime exception. > > Also, the following code: > > (println "hello") > (defn -main [args] > (println "world")) > > prints "hello" at compile time > and also > "hello > world" at runtime. > > My conclusions from this is that the static symbol checker is actually > fairly stupid and is just there to provide some simple sanity, and that all > toplevel code in a namespace > is executed at compile time AND at runtime. Is this correct? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Leiningen: referring to another project on local disc
Use lein install
This command will "install" your testgen jar in your local repo folder.
This local repo is hit first when searching for a dependency before escalating
to network repos if the dependency is not found there first.
No need for a uberjar.
Luc P.
> I'm trying to reference one of my leiningen projects from another, and not
> succeeding. My error must be simple and obvious...
>
> Essentially the projects 'poker' and 'testgen' are both in
> /home/simon/workspace, and both are standard leiningen projects using just
> the default project template. I've done 'lein uberjar' in testgen, so there
> are the following jars:
>
> simon@engraver:~/workspace/poker$ ls -l
> /home/simon/workspace/testgen/target/
> total 3588
> drwxr-xr-x 2 simon simon4096 Apr 2 20:04 classes
> -rw-r--r-- 1 simon simon 5 Apr 6 00:06 repl-port
> drwxr-xr-x 2 simon simon4096 Apr 2 20:04 stale
> -rw-r--r-- 1 simon simon 11226 Apr 6 00:10 testgen-0.1.0-SNAPSHOT.jar
> -rw-r--r-- 1 simon simon 3646079 Apr 6 00:10
> testgen-0.1.0-SNAPSHOT-standalone.jar
>
>
> In poker/project.clj I've done the following (added lines highlighted):
>
> (defproject poker "0.1.0-SNAPSHOT"
> :description "Poker scoring kata"
> :url "http://example.com/FIXME";
> :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
> :repositories [["testgen"
> "file:///home/simon/workspace/testgen/target"]]
> :dependencies [[org.clojure/clojure "1.5.1"]
> [testgen "0.1.0-SNAPSHOT"]
> ])
>
>
> When I try to run lein repl, I get the following:
>
> simon@engraver:~/workspace/poker$ lein repl
> Could not find artifact testgen:testgen:jar:0.1.0-SNAPSHOT in clojars
> (https://clojars.org/repo/)
> Could not find artifact testgen:testgen:jar:0.1.0-SNAPSHOT in testgen
> (file:///home/simon/workspace/testgen/target)
> This could be due to a typo in :dependencies or network issues.
>
>
> So clearly lein is failing to recognise the jar file(s) as the artefact
> it's looking for. What do I need to do differently? Do I need a pom file,
> and if so what should be in it?
>
> Cheers
>
> Simon
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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.
>
--
Softaddicts sent by ibisMail from my ipad!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Basic string modification question
Concatenation, replacing occurrences by another value, formatting values within a string are quite common. Playing with indexes within a string ? I rarely used this in the last 15 years. In the old days yes since space was at premium, many languages did not support dynamic allocations, speed was also much lower,... Just to be curious, (I did not read the whole thread), what are you representing with strings ? Luc P. > Thanks Josef, but could you explain a bit more. Are you saying that the > operation of replacing a substring (by index & length) with another > substring is not a common operation? > > i.e. > > (defn replace-substring [s r start len] (str (subs s 0 start) r (subs s (+ > len start > > If so, that does suprise me. I think I can better understand guns objection > on the basis that it would be a bad function for an immutable string > library, since the naming suggests mutability and also that if you wanted > to replace multiple substrings (which each would require several copy > operations) it would be (I think?) more efficient to do it in a single > expression involving multiple calls to substring, than using > replace-substring. But even so, there is already the function 'replace' in > clojure which also suggests mutability. > > However, not being from a a java background I was also quite surprised to > find out that there isnt a similar function in java > (http://stackoverflow.com/questions/14642978/replace-part-of-a-string-between-indexes-in-java). > > Im also interested in your second comment and was wondering what you mean > by transient string? > > Thanks > > Andy > > > > > > On Wednesday, 2 April 2014 19:05:48 UTC+1, Jozef Wagner wrote: > > > > No. IMO this is not a common operation and should not be in core. If you > > need do it a lot, you should not use java string in the first place. > > > > What should be included in core is a transient string, with support for > > assoc!. > > > > Jozef > > > > > > On Wed, Apr 2, 2014 at 7:49 PM, Andy Smith > > > > > wrote: > > > >> just a shame its not in the core, no? > >> > >> > >> On Wednesday, 2 April 2014 18:06:03 UTC+1, A. Webb wrote: > >>> > >>> Using subs (no need for join) is the way I would go, just define > >>> > >>> > >>> (defn replace-at [s n c] (str (subs s 0 n) c (subs s (inc n > >>> > >>> (replace-at "hello" 1 "a") ;=> "hallo" > >>> > >>> and carry on. > >>> > >>> > >>> > >> -- > >> 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.6.0-RC1 - LAST CHANCE, PLEASE TEST
Moved to this release 3 days ago. Nothing to report, works as expected :) Thank to everyone for this new release :) Luc P. > Hello all, > > We would love to release Clojure 1.6.0 final soon. > > We need your help in checking out the current release candidate - this is > your opportunity to let us know about problems *before* we release, rather > than after. > > Try it via > - Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-RC1 > - Leiningen: [org.clojure/clojure "1.6.0-RC1"] > > See the full change log here: > https://github.com/clojure/clojure/blob/master/changes.md > > If you have questions, feel free to drop them here. For issues, please log > them in JIRA <http://dev.clojure.org/jira/secure/Dashboard.jspa>. > > Alex > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: STM and persistent data structures performance on mutli-core archs
hould view Martin's other vidoes on infoq > <http://www.infoq.com/author/Martin-Thompson> to get a better > understanding of his arguments. He's actually quite positive about > Clojure in general. It's just that depending on the scalability and > performance requirements, persistent data structures may not provide a > satisfactory answer and could even lower throughput. > > > On 14/03/14 18:01, ?? ? wrote: > > He talks about simple things actually. > > > > When you have any sort of immutable data structure and you want to > > change it from multiple threads > > you just must have a mutable reference which points to the current > > version of that data structure. > > Now, updates to that mutable reference are fundamentally serial. > > Whatever synchronization > > strategy you chose been that optimistic updates (atom) or queuing > > (agent) or locks you inevitably > > will have a contention on a large number of threads. When you will run > > on that you will also > > have hundred ways to solve a problem. > > > > There is nothing magical about persistent data structures on > > multi-core machines :) > > > > ???, 13 ? 2014 ?., 20:58:54 UTC+4 Andy C ???: > > > > Hi, > > > > So the other day I came across this > > presentation:http://www.infoq.com/presentations/top-10-performance-myths > > <http://www.infoq.com/presentations/top-10-performance-myths> > > > > The guy seems to be smart and know what he talks about however > > when at 0:22:35 he touches on performance (or lack of thereof) of > > persistent data structures on multi-core machines I feel puzzled. > > > > He seems to have a point but really does not back it with any > > details. There is also a claim that STM does not cooperate well > > with GC. Is it true? > > > > 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. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.8
Hi, fixed a number of small issues. Noticeable changes: a) Multiple calls to trace-vars on the same var would require a similar number of calls to untrace-vars to remove the trace. Now a single call to untrace-vars will remove the trace, there are no more cumulative effects done by trace-vars. b) Only functions are now traced by trace-vars. 0.7.7 was skipped, bad readme... I registered an RSS feed to get notified when tickets are added to JIRA to this project. My reaction time should be better from now on... 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: map semantics
The sequence abstraction is documented here: http://clojure.org/sequences Clearly map is documented as working on sequences. A sequence is not a concrete type as explained by others on this thread. If you really need some specific behavior from a concrete type then do not rely on sequences. Use the concrete type directly in all your code. Choose the right tool to do your job. Clojure offers so many options that this should not be difficult. Luc P. > On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield wrote: > > > But you're misunderstanding what map does: it converts its collection > > arguments to _sequences_ and then it processes those sequences. Map > > doesn't operate on sets, or vectors, or maps, only on sequences. > > > > Your assertion that I "am misunderstanding something" is wrong. > > One cannot convert amorphic set into linear sequence without assuming > certain order. And as with every assumption, it always comes with some less > or more pragmatic but arbitrary decision which might change over time and > ruin peoples programs. > > I would expect Clojure to throw "IllegalArgumentException Don't know how to > create ISeq from: clojure.lang.PersistentHashSet" or document it well in > map somewhere. > > > "Perfection is the enemy of the good." > > > > Now judging by your sig, it all does not surprise me LOL > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: OOP question re: The Language of the System
hat has all these verbs and knows how to
> > do stuff ...".
> >
> > Clojure data types also have verbs, in protocols, and if one
> > component passes a record to another component, the receiver will
> > need to use those verbs to make use of the data. How is that
> > different than the OOP example? There's the syntactic difference
> > that in OOP you write it object, verb, arguments, and in clojure
> > you write it verb, object, arguments. But that's trivial. How is
> > it architecturally different to pass an object with methods vs
> > passing a record with protocol?
> >
> >
> > Protocols should be considered a tool for polymorphism, rather than a
> > tool for encapsulation. You shouldn't consider protocols to be tightly
> > coupled to a record or type.
> >
> > To give a more concrete example, consider a edn data structure like:
> >
> > #inst "2014-01-19T21:44:46.471-00:00"
> >
> > By default Clojure reads this as a java.util.Date object, but we could
> > equally read this as a org.joda.time.DateTime object, or
> > a hirondelle.date4j.DateTime object.
> >
> > All these implementations describe the same data, but will have subtly
> > different methods and interfaces. The data structure serialised in edn
> > doesn't mandate a particular class, or a particular set of methods.
> >
> > Similarly, if we imagine a data structure like:
> >
> > #myapp/Person {:first "Fred" :last "Mertz"}
> >
> > You should think of this as a map tagged with "#myapp/Person", not a
> > representation of a specific Clojure record that has a specific set of
> > functions. It's up to the receiver to interpret this data, and the
> > functions that operate on this data might differ between components.
> > For instance, a component that displays the data to the user might
> > have a function to derive a person's full name, but a component that
> > archives the data wouldn't need this functionality.
> >
> > - 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/groups/opt_out.
> > Brian Craft <mailto:craft.br...@gmail.com>
> > January 19, 2014 12:55 PM
> > http://www.youtube.com/watch?v=ROor6_NGIWU
> >
> > Around 56:28 Rich is talking about whether components pass a data
> > structure, or "an object that has all these verbs and knows how to do
> > stuff ...".
> >
> > Clojure data types also have verbs, in protocols, and if one component
> > passes a record to another component, the receiver will need to use
> > those verbs to make use of the data. How is that different than the
> > OOP example? There's the syntactic difference that in OOP you write it
> > object, verb, arguments, and in clojure you write it verb, object,
> > arguments. But that's trivial. How is it architecturally different to
> > pass an object with methods vs passing a record with protocol?
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient
> > with your first post.
> > To unsubscribe from 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/groups/opt_out
Re: nested #%'s
The reader does not support this and the reader is not configurable. Quite a final end to any counter...counter argument :) #() is syntactic sugar and not designed to play Russian puppets with anonymous fns :) (or Russian roulette ?) As a general remark, when you need imbricated anonymous fns in many places, it's probably a sign that you need a separate function or if really needed a macro to wrap this pattern. Code readability will improve accordingly. Luc P. > ## Question: > > Is there a way to do nested, #%'s, where each % matches to the nearest > "parent" #. > > ## Counter Argument: > > You don't want this, it makes Clojure code hard to read. > > ## Counter Counter Argument: > > Despite it being hard to read, I'd like to try it for a few months, and > see if I can adjust to reading two levels of nested # %'s. > > ## Question: > > Is there any library or extension to Clojure that allows nested #%'s? > > 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: JAVA_OPTS not accessible in my Clojure project
To set java properties on the cmd line you need to enter something like: -Djavax.net.ssl.keyStore=value try :jvm-opts ["-Djavax.net.ssl.keyStore=full-spec-of-your-file"] Luc P. > Hi Phill, > > Thanks for the heads up. > > I've entered this in project.clj > :jvm-opts ["javax.net.ssl.keyStore"] > > Restarted the CIDER REPL and entered in core.clj > > (System/getProperty "javax.net.ssl.keyStore") > > I evaluated that expression and it returns nil. > > But, if I go to the command-line and at the root of the project type 'lein > repl' > > a-project.core=> (System/getProperty "javax.net.ssl.keyStore") > > The certificate path is returned > > > ./certs/dev.bbc.co.uk.p12\ > > Many Thanks > > Aidy > > > > > > On 13 January 2014 00:25, Matching Socks wrote: > > > The Leiningen sample project > > https://github.com/technomancy/leiningen/blob/master/sample.project.clj > > refers to a :jvm-opts key and a JVM_OPTS environment variable. > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > -- > @AidyLewis > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Contributors needed for Rouge (Clojure on Ruby)
a7) > >> takes 9-12 seconds to start!!! not so tolerable... > >> in fact, in the absence of a splash screen, the user has the quite > >> convincing illusion that nothing is happening!!! > >> > >> this of course doesn't mean anything, I just thought it is worth > >> mentioning... > >> > >> Jim > >> > >> > >> > >> -- > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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/groups/opt_out. > >> > > > > > > > > -- > > “One of the main causes of the fall of the Roman Empire was that–lacking > > zero–they had no way to indicate successful termination of their C > > programs.” > > (Robert Firth) > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Clojure deployment questions w.r.t. jars, clojure source files, compiled class files
Look at the compile fn at the bottom: https://github.com/technomancy/leiningen/blob/master/src/leiningen/compile.clj you will find your answer :) Luc P. > Excellent answers and I usually find a use for extra wrenches. > > I'm still confused about when anybody actually calls the (compile) > function, any more tips here? Or is it being done for me by leiningen? > > > On Wed, Jan 8, 2014 at 1:54 AM, Softaddicts > wrote: > > > To complement my previous post and in relation to this one, > > we use (if-not *compile-file* ...) to wrap expressions that cannot be > > AOT compiied (like loading configuration or connecting to external > > resources which you do not want to do at compile time but at run time > > only:) > > > > This confused a lot of people in the past trying to use AOT. > > For many the compilation phase and code execution are perceived > > as a single step. When working in the REPL you do not need to be aware of > > this. With AOT it's important to be aware of the difference when writing > > code > > in dev. > > > > Luc P. > > > > > > > On Tue, Jan 7, 2014 at 4:26 PM, Dave Tenny wrote: > > > > 1) When and under what circumstances projects are compiled in source > > versus > > > > .class form? > > > > > > Most Clojure projects ship in source form (and are therefore compiled > > > to bytecode on demand as they are loaded). > > > > > > > 2) Why there is no project.clj in the org.clojure jar file? > > > > > > It's built with Maven. As are most of the Clojure contrib libraries > > > too, although some are now starting to sport project.clj files to make > > > local development easier. In the last round of development, I added > > > Leiningen support to clojure.java.jdbc to make it easier to "jack in" > > > with Emacs and test the code. It still uses Maven for primary testing > > > (on build.clojure.org) and packaging - and Clojure plus its contrib > > > libraries are hosted on Maven Central (where they are retrieved > > > primarily by Leiningen into other Clojure projects). > > > > > > > 3) When the clojure 'compile' function comes into play in your typical > > > > clojure project deployments? (vs. :aot targets or other leiningen > > deployment > > > > techniques). > > > > > > At World Singles, we AOT compile very little of our code. We only AOT > > > namespaces that generate Java-compatible classes for situations where > > > we must be natively callable from Java (e.g., we have a log4j appender > > > written in Clojure). Within that AOT-compiled code, we require > > > namespaces and resolve symbols dynamically (at runtime) to bind the > > > Java-called code to the rest of our code base. > > > > > > Part of the reason is for the flexibility that source deployments > > > provide: the ability to REPL into a live, running process and reload > > > code from updated source files without needing to "stop the world", > > > for example. > > > > > > If you're relatively new to Clojure, I'd recommend completely ignoring > > > the whole "compilation" thing unless you specifically need to generate > > > natively callable code for Java to Clojure interop. > > > > > > In case anyone is interested, our pattern for bridging from the > > > AOT-compiled namespace to the rest of the code base tends to look like > > > this: > > > > > > (def the-symbol > > > (delay > > > (do > > > (require 'the.namespace) > > > (resolve (symbol "the.namespace/the-symbol") > > > > > > and then: > > > > > > ... (@the-symbol arg1 arg2) ... > > > > > > Our AOT-compiled layer is deliberately minimal and serves only to > > > provide the Java-callable API so the rest of our code can be developed > > > and tested in our normal interactive, incremental way. > > > -- > > > Sean A Corfield -- (904) 302-SEAN > > > An Architect's View -- http://corfield.org/ > > > World Singles, LLC. -- http://worldsingles.com/ > > > > > > "Perfection is the enemy of the good." > > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > > > -- > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post t
Re: Extracting a database schema and using it to synthesize and check SQL queries at compile time
Hi, After struggling with Hibernate, SQL dsl, then bare SQL for a couple of years we took a radical path away from these approaches. We do not in our world own the database models we are dealing with, keeping our heads above water (or mud you might say) has become a survival issue. So we took the problem the other way around. How can we make the relational models compliant with our business model ? We are in the health industry, a patient is a patient, why do we have to struggle with the fine prints of each vendor's relational model ? We implemented and EDN subset library in several SQL db dialects (Oracle, mysql, SqlServer support will come out before spring). Implementing an EDN library is between 250 to 300 lines of SQL code per database type so far. It's purely functional and returns a single column (entity) and a string EDN representation. We just edn/read-string in the code and we get our business entity. What remains are semantic issues with the data itself but this already addressed by a component above this in our product stack. To avoid writing the views by hand, we created a viewer generator that creates according to the db dialect a view returning an EDN representation of the business entity as we manipulate it in the code, not as it is defined in the database. One view == one business entity. The generator is db aware through some protocol magic and can handle different db brands. The mapping between the db model and our business model is defined as data. It contains the fields to extract, their types if not strings, the joins, the selection criterias, the db dialect, This defines our business model vs the relational model. The generator is less than 300 lines of code, entity definitions can be between 50 to 200 lines. Add to this the yesql library to wrap queries now in a single file. It shrank our sql queries to a ridiculous number per vendor while pushing away the complexity of the mapping of the relational model away from the code as configurable data. As for inserts, updates, ... views are of no help here but the generator can bridge the gap by creating sql statements and small field name translation wrappers from the same definition as the views. The parameter names we use remain coherent with the business model the code uses. The sql statements to insert, ... are again wrapped by yesql. Performançe so far is not an issue, we run our product on small boxes less powerful than our customer's database servers. Shifting the load on the side of the database server made sense in this regard. And away from this relational modeling crap. Give the same business domain entities to ten different DBAs and you will get ten relational models each with it's own nit picking subtleties. Luc P. > Hey everyone, > > We've been exploring ways to make working with database code more efficient > and less error prone. > For complex queries, we prefer working directly with SQL. However, like for > many others, a lot of our > queries are very simple and repetitive. For example, retrieving or updating > single rows, or a set of rows > based on a foreign key. > > As an experiment, we wrote a prototype that uses the information_schema > standard to automatically > extract the schema from a database and represent it as clojure code at > compile time. With this, we > were able to synthesize some simple SQL queries. The interesting part of > this is that the code generator > automatically picks up primary key constraints and also performs validation > on table and column names. > All of this is done at compile time. Errors are caught early and the > compiled code uses clojure.java.jdbc > prepared statements. You can find the code and demo here: > > https://github.com/diligenceengine/edl > > I'm personally not a big fan of huge ORM systems, so I don't know where to > go with this, if anywhere. > Though it seems useful for building small macros for common patterns we > have. > > Would love to hear if anyone has thoughts on the technique. > > Alex > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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.g
Re: Clojure deployment questions w.r.t. jars, clojure source files, compiled class files
To complement my previous post and in relation to this one, we use (if-not *compile-file* ...) to wrap expressions that cannot be AOT compiied (like loading configuration or connecting to external resources which you do not want to do at compile time but at run time only:) This confused a lot of people in the past trying to use AOT. For many the compilation phase and code execution are perceived as a single step. When working in the REPL you do not need to be aware of this. With AOT it's important to be aware of the difference when writing code in dev. Luc P. > On Tue, Jan 7, 2014 at 4:26 PM, Dave Tenny wrote: > > 1) When and under what circumstances projects are compiled in source versus > > .class form? > > Most Clojure projects ship in source form (and are therefore compiled > to bytecode on demand as they are loaded). > > > 2) Why there is no project.clj in the org.clojure jar file? > > It's built with Maven. As are most of the Clojure contrib libraries > too, although some are now starting to sport project.clj files to make > local development easier. In the last round of development, I added > Leiningen support to clojure.java.jdbc to make it easier to "jack in" > with Emacs and test the code. It still uses Maven for primary testing > (on build.clojure.org) and packaging - and Clojure plus its contrib > libraries are hosted on Maven Central (where they are retrieved > primarily by Leiningen into other Clojure projects). > > > 3) When the clojure 'compile' function comes into play in your typical > > clojure project deployments? (vs. :aot targets or other leiningen deployment > > techniques). > > At World Singles, we AOT compile very little of our code. We only AOT > namespaces that generate Java-compatible classes for situations where > we must be natively callable from Java (e.g., we have a log4j appender > written in Clojure). Within that AOT-compiled code, we require > namespaces and resolve symbols dynamically (at runtime) to bind the > Java-called code to the rest of our code base. > > Part of the reason is for the flexibility that source deployments > provide: the ability to REPL into a live, running process and reload > code from updated source files without needing to "stop the world", > for example. > > If you're relatively new to Clojure, I'd recommend completely ignoring > the whole "compilation" thing unless you specifically need to generate > natively callable code for Java to Clojure interop. > > In case anyone is interested, our pattern for bridging from the > AOT-compiled namespace to the rest of the code base tends to look like > this: > > (def the-symbol > (delay > (do > (require 'the.namespace) > (resolve (symbol "the.namespace/the-symbol") > > and then: > > ... (@the-symbol arg1 arg2) ... > > Our AOT-compiled layer is deliberately minimal and serves only to > provide the Java-callable API so the rest of our code can be developed > and tested in our normal interactive, incremental way. > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles, LLC. -- http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Clojure deployment questions w.r.t. jars, clojure source files, compiled class files
bers are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Possible to "dual license" open source Clojure project under EPL with commercial option?
Re-reading your email, I realize that you may want to license the same code both as an open source and as a commercial product. >From a customer perspective, if they use it as a binary why not. If you are the author of the software you can license it as you wish. Now if your customer get access to the same source code that may be hard to manage. Can you clarify a bit your intent ? Luc P. > > This may help you. > > http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER > > If you are not modifying/reusing the licensed source code > in your own code and are using the licensed software as a binary component > then what you create on top of it is your own. > > I you touch the source code of the licensed software in any way then it > becomes > more complex. You have to make the source code of your mods > available (assuming you distribute your software in any way) > and it has to be licensed under the EPL. > > And this may in turn restrict how you license your own creation. > > If you avoid the latter case, you should be fine. > > Luc P. > > > Do any Clojure developers have experience with "dual licensing" an open > > source Clojure project under the EPL with the option of a commercial > > license? > > > > I have in mind corporate customer-developers for one of my projects who > > aren't comfortable with the terms of the EPL – i.e. they desire to embrace > > and extend without bumping into the reciprocal clauses of the EPL. > > > > It seems to me the EPL doesn't prohibit the option of a commercial license. > > But I'm wondering if this kind of thing has been done or is being done > > with EPL'd open source Clojure codebases. > > > > I'm sure I would need the services of an IP lawyer to make sure the fine > > print is in good order, but I would appreciate input from the readers here > > as well. > > > > Thanks. > > > > -- > > Michael Bradley > > @michaelsbradley > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Possible to "dual license" open source Clojure project under EPL with commercial option?
This may help you. http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER If you are not modifying/reusing the licensed source code in your own code and are using the licensed software as a binary component then what you create on top of it is your own. I you touch the source code of the licensed software in any way then it becomes more complex. You have to make the source code of your mods available (assuming you distribute your software in any way) and it has to be licensed under the EPL. And this may in turn restrict how you license your own creation. If you avoid the latter case, you should be fine. Luc P. > Do any Clojure developers have experience with "dual licensing" an open > source Clojure project under the EPL with the option of a commercial > license? > > I have in mind corporate customer-developers for one of my projects who > aren't comfortable with the terms of the EPL – i.e. they desire to embrace > and extend without bumping into the reciprocal clauses of the EPL. > > It seems to me the EPL doesn't prohibit the option of a commercial license. > But I'm wondering if this kind of thing has been done or is being done > with EPL'd open source Clojure codebases. > > I'm sure I would need the services of an IP lawyer to make sure the fine > print is in good order, but I would appreciate input from the readers here > as well. > > Thanks. > > -- > Michael Bradley > @michaelsbradley > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Namespaces [was Re: Is Clojure right for me?]
ody uses shared-info) > > Call these functions via: > > (foo info 2) > (bar info 3) > > > My argument is that both these solutions are unsatisfying. Solution 2 is > irritating because if you use a map for shared-info, you end up having to > repeat the destructuring in every single function. Also, you need to > thread this information through all the functions, not only the functions > that directly use, but also the functions that call other functions that > use it. It makes all the functions bulky and awkward, and at the end of > that, you still don't have something that reflects the notion of getting > back a group of functions that share the *same* info -- instead, you have > to remember to always pass in that same info with every function call. > Also, with the threading-the-state version, you don't have a convenient > notion of "default state", unless you are willing to take cases on the > number of arguments for every single one of your functions. > > My other claim is that "Solution 2" feels too heavy-handed for small > projects, or scenarios where it isn't clear you'll ever want to initialize > the shared-info to something other than the defaults, but the path of > transition from Solution 1 to Solution 2 is a painful one. > > > I think that where my experience differs from yours is summarized in your > > comment "In Clojure, a project often begins with a bunch of functions > > sharing some immutable state or "magic constants" stored in vars." I > > *never* do that. If there are a group of related things, I put them in an > > associative container (maybe just a map) on day one. > > > > Even if you share all those constants in an immutable container, I maintain > that the threading of that information through all the functions can be > awkward. > > > > > > The analogy with OO is misleading here. If you started an OO project > > putting everything in static/singleton members, you would have the same > > pain you attribute to Clojure's namespaces. > > > > Not necessarily. Sure, you'd have to delete all the "static" words from > your methods. And you'd need to make sure you then accessed the methods > through an instance, but fundamentally, you wouldn't need to change the > body of any of the methods or the number of inputs in callers or callees. > I suspect in a language like Scala, you could probably even find a way to > leave behind a "companion object" that forwards to a default instance, so > your old static/singleton calls still work. > > So yes, I agree that there would be some similar issues in moving from a > singleton to an instance-based scheme in an OO language, but I don't think > the change would be as dramatic as the same transition in Clojure. > > > > > > I find this to be a "my car doesn't have wings" argument, and the kind of > > thing that leads into casually complecting everything with everything else. > > > > > If there is an idiomatic way in Clojure to solve this problem other than > the two solutions I've outlined above, I'd love to see 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Is Clojure right for me?
t; > to use > > > > for my production code. That would be time-inefficient because my goal > > in > > > > not to learn languages, but to pick up a new language suitable for my > > needs. > > > > > > > > On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: > > > > > > > > > > This depends strictly on your learning speed which I will > > > > > not comment here :) > > > > > > > > > > It took me three months full time to start to feel at ease with > > > > > Clojure writing production code and I was around 45 years > > > > > old at the time. > > > > > > > > > > Learning is never inefficient... when you want to learn. > > > > > > > > > > Luc P > > > > > > > > > > > > > > > > On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: > > > > > > > > > > > > > > Ok I'll drop the subject. Still cannot understand why people > > cannot > > > > > > > try something new w/o sticking to the stuff they know already > > until > > > > > they > > > > > > > are > > > > > > > totally immersed in the new thing. And by that I mean use the > > new > > > > > thing as > > > > > > > it was intended. > > > > > > > > > > > > > > Then you can generate useful conclusions and get some benefits > > from > > > > > > > this learning process. > > > > > > > > > > > > > > > > > > > Learning every single language just to find the right one is not > > very > > > > > > time-efficient. > > > > > > > > > > > > -- > > > > > > -- > > > > > > 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/groups/opt_out. > > > > > > > > > > > -- > > > > > 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 > > > > 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/groups/opt_out. > > > > > > > -- > > > 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 clo...@googlegroups.com > > > Note that posts from new members are moderated - please b
Re: Is Clojure right for me?
Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. I was just teasing a bit :) If I were to be combative, it would be much worse :) Luc P. > On 26 Dec 2013 21:04, "Softaddicts" wrote: > > > > a) encapsulation of unmutable state ? What for ? > > b) inheritance ? see a) > > c) polymorphism ? Multimethods (which are more flexible) or protocols > > > > Nice words but not much else. > > > > Comparing C versus C++ is fair but this comparison does not relate at all > to > > Clojure, it's like answering "blue" to the question > > "which even number sits between 1 and 3 ?" > > > > I am still waiting for an answer to my previous post btwy... > > Let's be nice. We're supposed to have a welcoming community, not a > combative one :) > > - 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Is Clojure right for me?
a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering "blue" to the question "which even number sits between 1 and 3 ?" I am still waiting for an answer to my previous post btwy... Luc P. > On Thursday, December 26, 2013 9:01:56 PM UTC+1, HamsterofDeath wrote: > > > > exactly which part of OOP is missing in clojure that you would like to use? > > if you took my java code and ported it to clojure, the main difference > > would be (a b) instead of b.a , but the main design would be similar > > > > How can that be? What about encapsulation, inheritance and polymorphism? > OOP is not just syntactic sugar. > If I were to implement something (complex enough) in C and C++ the > differences between my implementations would be far from superficial. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Is Clojure more functional then Scala?
The url should have been this one:
http://rotpier27.files.wordpress.com/2012/01/chimc3a8re.jpg
}^}%}%}{[+{^ iPhone screen... too small for my big fingers...
> In 2008 I was reviewing options,
> we had to move away from Java.
>
> I choose Clojure rather than Scala,
> I found Scala quite confusing.
> Attempts to pour in FP notions
> in an OO language looked too me
> as an attempt to transplant a fifth
> limb to a four limb made body.
>
> Since then I had a few discussions
> with Scala developers and the
> answers I got made it clear to me
> that choosing Clojure is a better
> choice.
>
> The common ground to these answers
> is 'do not use mutable collections',
> 'use values...','this is bad practice,...'
>
> I never got a satisfying answer to
> my counter questions 'then why offer
> all these features (mutation, objects, ...) easily accessible,
> if they are not to be used ?
> And how a newbie is suppose to know
> how to avoid all these sand traps ?
>
> If you want to use mutation in
> Clojure, it's doable but it also
> colors your code in a way that makes
> it obvious and exceptional somehow.
>
> Clojure sits at the frontier but with
> a bias toward FP while being
> pragmatic.
>
> We have a problem in this industry,
> features inflation. At some point
> it becomes useless to add not so
> natural features to a language.
>
> Scala is OO derived and adding FP
> features will not change it's DNA.
>
> Look at what Java 8 promises and
> it will end up in some form of chaos.
>
> Just thinking at what a mixed Java
> code base will look like in 10 years
> gives me nausea :)
>
> Yes there's a plan to make Cobol
> OO aware.
>
> It's not because it's doable that we
> should to do it.
>
> http://rotpier.over-blog.com/article-97207983.html
>
>
> Luc P.
>
> > I jumped on the FP bandwagon over a year ago and have been using Scala both
> > at work and for personal interest. Recently however I decided to take a
> > closer look at Clojure and see if it is something i actually like. I have
> > to admit at first the syntax form was awkward, but im starting to really
> > see the simplicity behind it.
> >
> > I have heard many people claim that Clojure sets you up and supports you
> > for FP more so then Scala does. However they never provide any examples of
> > something Clojure does that is more supporting of FP then the way idiomatic
> > Scala does it.
> >
> > Here are some things that I have heard people say when comparing Clojure vs
> > Scala in reference to FP
> > Clojure has immutable persistance data structures. but so does Scala
> > Scala also tries to get you to use its immutable collections, like Vectors,
> > and are also persistent data structures. However they are not as uniform as
> > Clojures Seq i agree with that.
> >
> > Also Scala recommends using vals and not vars, which gives you immutable
> > references points
> >
> > I am certainly learning towards dropping Scala for a bit and giving Clojure
> > a real shot. The reason i even picked up Scala was because i wanted to
> > learn more about FP, and if there is a better tool for both doing and
> > learning FP then i want it.
> >
> > So tell me, if you have used both Scala and Clojure, do you have some real
> > examples of some things where Clojure really does support you better when
> > doing FP, where Scala really leads you no way, or worse the imperative way?
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To 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/groups/opt_out.
> >
> --
> 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@googlegrou
Re: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.
Gaz, excuse me if I misunderstood you, I reread your reply and it was not clear to me to whom you were referring in your comment. I still stand by what I said toward the op. Saying that if rewritten the code would be the same as the original is a lame excuse, it's the same as all that internet cheating thing in schools. Unexcusable. Luc P. > You have the typical profile of people who do not understand open source. > To you, open source is the same thing has a side hobby, ... > with lack of commitment and seriousness. > > How do you expect open source software quality to improve if each of us > starts to spin off our own flavor of the same lib ? > How is this a constructive cooperating effort ? > How can open source software be used in production in this context ? > > Some people are using this stuff to build serious solutions to hard problems. > > I will not even rant about copying without the copyright. > > It's the overall lack of logic and self centric egoism that you exhibit that > makes > me rant. > > You should apply the maxim you have thrown in this thread to yourself. > You are much more representative of it than anyone else I saw > on this mailing list in 5 years. > > Punk. > > Luc P. > > > "Because there is no patch for human stupidity"? > > > > > > On Tue, Nov 19, 2013 at 1:35 PM, Sean Corfield > > wrote: > > > > > On Sun, Nov 17, 2013 at 1:57 AM, Andrey Antukh wrote: > > > > Additionally I have > > > > copied some useful functions like parsing dbspec to URI or a map of > > > > protocol->cases > > > > and the rest are written from scratch. > > > > > > Looking through the source code, there are quite a few functions > > > copied directly from parts of java.jdbc - even maintaining docstrings, > > > making it clear you copied and pasted them - but I notice that you > > > have not maintained the copyright or license from java.jdbc. > > > > > > Would you like to explain why you have copied open source software > > > without respecting the license and contributors? > > > -- > > > Sean A Corfield -- (904) 302-SEAN > > > An Architect's View -- http://corfield.org/ > > > World Singles, LLC. -- http://worldsingles.com/ > > > > > > "Perfection is the enemy of the good." > > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > > > -- > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > > --- > > > 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/groups/opt_out. > > > > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.c
Re: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.
You have the typical profile of people who do not understand open source. To you, open source is the same thing has a side hobby, ... with lack of commitment and seriousness. How do you expect open source software quality to improve if each of us starts to spin off our own flavor of the same lib ? How is this a constructive cooperating effort ? How can open source software be used in production in this context ? Some people are using this stuff to build serious solutions to hard problems. I will not even rant about copying without the copyright. It's the overall lack of logic and self centric egoism that you exhibit that makes me rant. You should apply the maxim you have thrown in this thread to yourself. You are much more representative of it than anyone else I saw on this mailing list in 5 years. Punk. Luc P. > "Because there is no patch for human stupidity"? > > > On Tue, Nov 19, 2013 at 1:35 PM, Sean Corfield wrote: > > > On Sun, Nov 17, 2013 at 1:57 AM, Andrey Antukh wrote: > > > Additionally I have > > > copied some useful functions like parsing dbspec to URI or a map of > > > protocol->cases > > > and the rest are written from scratch. > > > > Looking through the source code, there are quite a few functions > > copied directly from parts of java.jdbc - even maintaining docstrings, > > making it clear you copied and pasted them - but I notice that you > > have not maintained the copyright or license from java.jdbc. > > > > Would you like to explain why you have copied open source software > > without respecting the license and contributors? > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View -- http://corfield.org/ > > World Singles, LLC. -- http://worldsingles.com/ > > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > 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/groups/opt_out. > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Regarding Clojure's license
Hi, Not only your tone is inappropriate but you seem to really expect that the license scheme will change after nearly 6 years ? On what basis ? Your "legal" advice ? Against what we have all been experiencing in the last six years ? Please do us a favor, do some readings first before posting and soften the tone a bit, We will all be grateful :) Most of the stuff surrounding Clojure has been the subject of some careful decision process. Keep this in mind. Thank you, Luc P. > "I will not be dual licensing with GPL or LGPL. Both licenses allow the > creation of derived works under GPL, a license I cannot use in my > work. Allowing derived works I cannot use is not reciprocal and make > no sense for me." > > 1. First, the license allow proprietary derivative works anyway. > 2. That's also the point of the GPL. It is intended to make any derivative > work available to the author usable to the author. > > Thus, Rich Hickey's choice of the EPL has the same rationale as the GPL. > That violates the principle of free software. License incompatibilities > like this divide the open-source community. Please change. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: [ANN] Yesql 0.2.1 - Clojure & SQL queries rethought.
Ha ! Ha ! Never thought of this approach and frankly it's the simplest one. We create various db adapters and we routinely have to switch between raw SQL statements and express them to run from Clojure and it's been an extra step that yields zero value. Not as painfull as using an ORM but still annoying. Will mess with it definitively and let you know how it went. Luc P. > https://github.com/krisajenkins/yesql > > Yesql is a simple library for blending SQL & Clojure together, cleanly. > Here's how it works <https://github.com/krisajenkins/yesql#rationale>, and > how > to use it <https://github.com/krisajenkins/yesql#example-usage>. > > Feedback welcomed, > Kris > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: get fn and not-found
You are getting my-foo evaluated, remove the parens around it.
Luc P.
> Hello,
>
> I am trying to understanding why is this happening:
>
> > (defn my-foo [] (println "Why do I get printed?"))
> > #'sandbox4724/my-foo
> > > (get {:b 1} :b (my-foo))
> > Why do I get printed?
> > 1
> > >
>
>
> Shouldn't (my-foo) only be called in case the key isn't found? Why am I
> seeing the above behavior instead?
>
> Thank you for your time,
>
> Ryan
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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/groups/opt_out.
>
--
Softaddicts sent by ibisMail from my ipad!
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/groups/opt_out.
Re: Compulsive over-optimization
I read your post three times and now I need to get a couple of fuses replaced :) Holy smoke, it's Saturday man ! Most of us are probably trying to recover from the work week, give us a chance :))) Luc P. > The question in the second paragraph depends on the belief that someone > could engage in pointless refactoring. > > There is an implied assertion that clojure's design provides more > opportunities for someone to engage in pointless refactoring. > > Disproving that someone could engage in pointless activity would miss > the point of the question. So, providing an example for that would > possibly lead to more confusion. > > If the implied asssertion about clojure's design were taken to further > imply that the design is flawed in those cases, this would also be > missing the point of the question. > > If cases in which clojure's design were flawed were not invented for > the purpose of pursuing this questioning. Without criticism of clojure's > design, specifics about how clojure could be used in a multitude of ways > to solve a problem, could be described by way of example. But, that > would also miss the point of the question. > > So, if the image of someone engaging in pointless refactoring reminds > you of an experience that you have had, and if you can use that as the > model for a general case, how would you suggest preventing the general > case from being made actual, in the future? > > Kendall > > On 10/19/2013 12:35 AM, Laurent PETIT wrote: > > Can you give a concrete example? > > > > Le samedi 19 octobre 2013, Kendall Shaw a écrit : > > > > With clojure in particular, I am having trouble not rearranging my > > code to be what I think is more optimal in ways that seem probably > > not practical. I've noticed myself doing that when I'm newish to > > languages and apis. But, I go bonkers with clojure. > > > > Do you have any thoughts about how to avoid that, other than Bob > > Newhart's advice: > > > > Bob Newhart-Stop It <http://www.youtube.com/watch?v=Ow0lr63y4Mw> > > > > Kendall > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from 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/groups/opt_out. > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from 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/groups/opt_out. > > > -- > ThisIsHardToRead, asIsThis. This_is_easier, unless_it_is_underlined. > This.is.easy. This-is-easy-too. Almost as easy to read as this. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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 e
Re: Dependency management
We have been using archiva for a long time. Less sophisticated than nexus but a lot simpler to set up, at least that was the state of things more than 2 years ago. Luc P. > I've used an old version of Archiva, and we currently use Nexus. Nexus was > the better experience. > > > On Thu, Oct 17, 2013 at 12:05 PM, Shantanu Kumar > wrote: > > > There are also Archiva[1] and Artifactory[2]. > > > > [1] http://archiva.apache.org/index.cgi > > [2] http://www.jfrog.com/home/v_artifactory_opensource_overview > > > > Shantanu > > > > > > On Thursday, 17 October 2013 21:26:09 UTC+5:30, Ben Mabey wrote: > >> > >> On 10/17/13 9:38 AM, Andrei Serdeliuc wrote: > >> > Hi, > >> > > >> > I was wondering how people handle dependencies that aren't on clojars. > >> > We have a couple of clojure libs which are hosted on an internal > >> > github enterprise. > >> > > >> > So far I've been using lein's checkouts feature, but this seems fairly > >> > difficult when trying to setup continuous integration. As far as I can > >> > tell, lein doesn't support git dependencies. > >> > > >> > I've been thinking about maybe setting up an internal maven repo, but > >> > that seems like overkill. > >> > > >> > Any suggestions? > >> > > >> > Thanks! > >> > > >> Honestly, my suggestion is to setup a maven repo. Nexus[1] has a free > >> version and is easy to setup. If you really don't want to do that then > >> you can deploy your artifacts to S3 using the lein-wagon[2] plugin. > >> > >> -Ben > >> > >> > >> 1. http://www.sonatype.org/nexus/**go <http://www.sonatype.org/nexus/go> > >> 2. > >> https://github.com/**technomancy/s3-wagon-private<https://github.com/technomancy/s3-wagon-private> > >> > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
I hate "quirks", too many things to achieve, less time remaining, less brain estate to remember quirks :) Luc P. > Oh! > > I don't hate JavaScript ;-) > > I'm not a Clojure programmer, (and not a ClojureScript programmer). But I > usually program in C#, Java, PHP and JavaScript. I know Lisp, Ruby and > Python, but I don't "work" with them, only toy projects. > > I found JavaScript the most flexible programming language (less ceremony > than Ruby or Python), and combined with Node.js at server, browsers at > client, JSON for messaging, and TDD, it shines! > > Any quirk on JS language is easy to circumvent (ie. using module pattern, > build and exercised with TDD), and IMO, it pays a lot to use it. > > Angel "Java" Lopez > @ajlopez > > > > On Wed, Oct 9, 2013 at 9:26 AM, Softaddicts > wrote: > > > Yeah but I hate JavaScript so no wonder it's not on the list. > > I do however code in ClojureScript and avoid JS interop like > > the plague as much as possible :) > > > > I had to deal too much with browser based GUIs before things like JQuery > > > > and similar things came to life or because the back end framework did not > > allow me to use something more brilliant than plain JS... it got me > > disgusted > > pretty much. > > > > ClojureScript has changed my approach to browser based apps but > > w/o JS as much as possible, now I can conceal my app logic in the > > browser while using the back end as a resource provider. > > > > No more Dr Jekyll and Mr Hide syndrom... > > > > Luc P. > > > > > > > And JavaScript is missing (OK, "a dozen scripting language") > > > But today, JavaScript is very important in the picture. > > > Even Clojure has ClojureScript > > > > > > > > > On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt > > wrote: > > > > > > > especially haskell & scala are missing in your list :) > > > > as long as you haven't at least seen haskell, you haven't seen the > > creme > > > > de la creme of statically typed languages > > > > > > > > > > > > 2013/10/9 Softaddicts > > > > > > > >> Let's see: > > > >> > > > >> strong data typing: > > > >> > > > >> Fortran > > > >> Cobol > > > >> Pl/1 > > > >> Pascal > > > >> C/C++ > > > >> Java > > > >> C# > > > >> Ruby > > > >> > > > >> à la carte data typing or no data typing at all: > > > >> > > > >> Basic (more or less depending on the implementation) > > > >> Lisp > > > >> Clojure > > > >> A dozen assemblers > > > >> A dozen scripting languages > > > >> > > > >> And I probably forgot some while excluding the ones I worked with > > > >> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones > > > >> on real projects at work and not small projects. > > > >> > > > >> Lets keep SQL out of the picture, it's an exaggeration to call this a > > > >> programming > > > >> language. > > > >> > > > >> Still prefer less data typing or no typing at all :) > > > >> > > > >> Luc P. > > > >> > > > >> > > > >> > let's see... > > > >> > really used: > > > >> > sql > > > >> > java > > > >> > javascript > > > >> > basic > > > >> > pascal/delphi > > > >> > scala > > > >> > > > > >> > experimented with: > > > >> > logo (some old language intended to teach people to make their first > > > >> steps) > > > >> > haskell > > > >> > kotlin > > > >> > clojure > > > >> > > > > >> > seen in action: > > > >> > php > > > >> > groovy > > > >> > > > > >> > still prefer smart static typing :D > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > 2013/10/9 Nando Breiter > > > >> > > > > >> > > > > > >> > >> The best exp
Re: How to go about 'proving' why dynamically typed languages are better.
Yeah but I hate JavaScript so no wonder it's not on the list. I do however code in ClojureScript and avoid JS interop like the plague as much as possible :) I had to deal too much with browser based GUIs before things like JQuery and similar things came to life or because the back end framework did not allow me to use something more brilliant than plain JS... it got me disgusted pretty much. ClojureScript has changed my approach to browser based apps but w/o JS as much as possible, now I can conceal my app logic in the browser while using the back end as a resource provider. No more Dr Jekyll and Mr Hide syndrom... Luc P. > And JavaScript is missing (OK, "a dozen scripting language") > But today, JavaScript is very important in the picture. > Even Clojure has ClojureScript > > > On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt wrote: > > > especially haskell & scala are missing in your list :) > > as long as you haven't at least seen haskell, you haven't seen the creme > > de la creme of statically typed languages > > > > > > 2013/10/9 Softaddicts > > > >> Let's see: > >> > >> strong data typing: > >> > >> Fortran > >> Cobol > >> Pl/1 > >> Pascal > >> C/C++ > >> Java > >> C# > >> Ruby > >> > >> à la carte data typing or no data typing at all: > >> > >> Basic (more or less depending on the implementation) > >> Lisp > >> Clojure > >> A dozen assemblers > >> A dozen scripting languages > >> > >> And I probably forgot some while excluding the ones I worked with > >> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones > >> on real projects at work and not small projects. > >> > >> Lets keep SQL out of the picture, it's an exaggeration to call this a > >> programming > >> language. > >> > >> Still prefer less data typing or no typing at all :) > >> > >> Luc P. > >> > >> > >> > let's see... > >> > really used: > >> > sql > >> > java > >> > javascript > >> > basic > >> > pascal/delphi > >> > scala > >> > > >> > experimented with: > >> > logo (some old language intended to teach people to make their first > >> steps) > >> > haskell > >> > kotlin > >> > clojure > >> > > >> > seen in action: > >> > php > >> > groovy > >> > > >> > still prefer smart static typing :D > >> > > >> > > >> > > >> > > >> > 2013/10/9 Nando Breiter > >> > > >> > > > >> > >> The best explanation of these misunderstandings I've come across is > >> "What > >> > >> to Know Before Debating Type Systems": > >> > >> > >> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ > >> > >> > >> > >> > >> > > I have learned quite a lot from reading this article and following > >> this > >> > > discussion, particularly that "type" and "type checking" is much more > >> > > nuanced and complex than I have understood until now, and that the > >> terms > >> > > "static" and "dynamic" expand into a much larger range of issues upon > >> close > >> > > examination, such as the difference between explicitly declaring > >> types (as > >> > > in Java) and implicitly inferring types from code context. Quoting > >> from the > >> > > article: > >> > > > >> > > *Many programmers approach the question of whether they prefer static > >> or > >> > > dynamic types by comparing some languages they know that use both > >> > > techniques. This is a reasonable approach to most questions of > >> preference. > >> > > The problem, in this case, is that most programmers have limited > >> > > experience, and haven’t tried a lot of languages. For context, here, > >> six or > >> > > seven doesn't count as “a lot.”* > >> > > * > >> > > * > >> > > > >> > > So I can say I prefer dynamic typing, but the reasons are more > >> personal, > >> > > and molded by my development experi
Re: How to go about 'proving' why dynamically typed languages are better.
That's what I said earlier, I need to find some type to dive into it. As far as Scala is concerned, it's not on my list of items to learn. Too Java-ish to me and clunky. It's not because you mix all the latest features in a single language that the result is a significant landmark. It took a significant amount if time to Haskell designers to think about feature set, it's not the same caliber at all. Before choosing Clojure for our product, I looked at it and rejected it and still have no regrets doing so. Java in it's future releases will follow on the same slippery road of feature aggregation w/o coherency, the "let's please everyone" approach never led to anything exceptional. It makes only things more confusing thanks to these guys... http://search.dilbert.com/search?p=R&srid=S3-USESD01&lbc=dilbert&w=marketing%20idea&url=http%3a%2f%2fdilbert.com%2fstrips%2fcomic%2f1999-02-06%2f&rk=7&uid=203834662&sid=2&ts=custom&rsc=YmDLFs%3as9q%3aosTfU&method=and&isort=date&view=list&filter=type%3acomic Luc P. > especially haskell & scala are missing in your list :) > as long as you haven't at least seen haskell, you haven't seen the creme de > la creme of statically typed languages > > > 2013/10/9 Softaddicts > > > Let's see: > > > > strong data typing: > > > > Fortran > > Cobol > > Pl/1 > > Pascal > > C/C++ > > Java > > C# > > Ruby > > > > à la carte data typing or no data typing at all: > > > > Basic (more or less depending on the implementation) > > Lisp > > Clojure > > A dozen assemblers > > A dozen scripting languages > > > > And I probably forgot some while excluding the ones I worked with > > (Algol, Simula, GPSS, ...) in academic projects. I used the above ones > > on real projects at work and not small projects. > > > > Lets keep SQL out of the picture, it's an exaggeration to call this a > > programming > > language. > > > > Still prefer less data typing or no typing at all :) > > > > Luc P. > > > > > > > let's see... > > > really used: > > > sql > > > java > > > javascript > > > basic > > > pascal/delphi > > > scala > > > > > > experimented with: > > > logo (some old language intended to teach people to make their first > > steps) > > > haskell > > > kotlin > > > clojure > > > > > > seen in action: > > > php > > > groovy > > > > > > still prefer smart static typing :D > > > > > > > > > > > > > > > 2013/10/9 Nando Breiter > > > > > > > > > > >> The best explanation of these misunderstandings I've come across is > > "What > > > >> to Know Before Debating Type Systems": > > > >> > > > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ > > > >> > > > >> > > > > I have learned quite a lot from reading this article and following this > > > > discussion, particularly that "type" and "type checking" is much more > > > > nuanced and complex than I have understood until now, and that the > > terms > > > > "static" and "dynamic" expand into a much larger range of issues upon > > close > > > > examination, such as the difference between explicitly declaring types > > (as > > > > in Java) and implicitly inferring types from code context. Quoting > > from the > > > > article: > > > > > > > > *Many programmers approach the question of whether they prefer static > > or > > > > dynamic types by comparing some languages they know that use both > > > > techniques. This is a reasonable approach to most questions of > > preference. > > > > The problem, in this case, is that most programmers have limited > > > > experience, and haven’t tried a lot of languages. For context, here, > > six or > > > > seven doesn't count as “a lot.”* > > > > * > > > > * > > > > > > > > So I can say I prefer dynamic typing, but the reasons are more > > personal, > > > > and molded by my development experience. > > > > > > > > -- > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Clojure&q
Re: How to go about 'proving' why dynamically typed languages are better.
Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. > let's see... > really used: > sql > java > javascript > basic > pascal/delphi > scala > > experimented with: > logo (some old language intended to teach people to make their first steps) > haskell > kotlin > clojure > > seen in action: > php > groovy > > still prefer smart static typing :D > > > > > 2013/10/9 Nando Breiter > > > > >> The best explanation of these misunderstandings I've come across is "What > >> to Know Before Debating Type Systems": > >> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ > >> > >> > > I have learned quite a lot from reading this article and following this > > discussion, particularly that "type" and "type checking" is much more > > nuanced and complex than I have understood until now, and that the terms > > "static" and "dynamic" expand into a much larger range of issues upon close > > examination, such as the difference between explicitly declaring types (as > > in Java) and implicitly inferring types from code context. Quoting from the > > article: > > > > *Many programmers approach the question of whether they prefer static or > > dynamic types by comparing some languages they know that use both > > techniques. This is a reasonable approach to most questions of preference. > > The problem, in this case, is that most programmers have limited > > experience, and haven’t tried a lot of languages. For context, here, six or > > seven doesn't count as “a lot.”* > > * > > * > > > > So I can say I prefer dynamic typing, but the reasons are more personal, > > and molded by my development experience. > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
demic weight > > behind this. The only counter I could come up with was to use Godel's > > incompleteness theorem. For those that don't know... here is an > > introduction to the man and his theory. > > http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, > > invalidated Principia Mathematica as a complete system of description. > > Principia Mathematica btw effectively led to Type Theory. > > > > > > According to http://en.wikipedia.org/wiki/Type_theory. "The types > > of type theory were invented by Bertrand Russell in response to > > his discovery that Gottlob Frege's version of naive set theory was > > afflicted with Russell's paradox. This theory of types features > > prominently in Whitehead and Russell's Principia Mathematica. It > > avoids Russell's paradox by first creating a hierarchy of types, > > then assigning each mathematical (and possibly other) entity to a > > type. Objects of a given type are built exclusively from objects > > of preceding types (those lower in the hierarchy), thus preventing > > loops." > > > > I'm hoping to collect a few more `proofs` from the clojure > > community... for example... if there is a paper on "why are type > > systems so bad at classifying animals"... then please forward it on. > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient > > with your first post. > > To unsubscribe from 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/groups/opt_out. > > > -- > ThisIsHardToRead, asIsThis. This_is_easier, unless_it_is_underlined. > This.is.easy. This-is-easy-too. Almost as easy to read as this. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
tient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: why does "ps aux" show a dump of my whole app?
ot;nREPL server started on > port" port__4369__auto__)) (clojure.core/spit > "/Users/larry/projects/walnut_admin/target/repl-port" port__4369__auto__) > (.deleteOnExit (clojure.java.io/file > "/Users/larry/projects/walnut_admin/target" "repl-port")) > (clojure.core/deref (clojure.core/promise) > > > Why, exactly? How is all of this in response to "ps"? > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: The Eclipse Public License is not a good license
Being filed by the NSA ? Oups, too late :) Luc P. > > Seriously? Your problem is that a contributor has to state that they > have added something? Why are you worried about this? > > Musical Notation writes: > > >> Each Contributor must identify itself as the originator of its > >> Contribution, > >> if any, in a manner that reasonably allows subsequent Recipients to > >> identify > >> the originator of the Contribution. > > > > That's my problem. > > > > On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) > > wrote: > > > >> > >> This is an interesting thread. I think, though, it repeats what is a > >> misconception about GPL -- that you cannot produce GPL code using > >> Clojure. This isn't true, as far as I can see -- you can write GPL code > >> using any language, because it doesn't usage restrictions in GPL do not > >> percolate through a "standard interface". > >> > >> So, for instance, my own library is covered by LGPL; it is possible to > >> link this to GPL code without problems. > >> > >> Historically, the first GPL products (Emacs for example) were built > >> using on non GPL platforms; it is the same issue. > >> > >> Sean Corfield writes: > >>> Searching the archives would have turned up some _long_ threads about > >>> this where it would have been clear that the license is not going to > >>> change - as well as explaining why it is the way it is. For example: > >>> https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from > >>> 2008) > >>> > >>> Sean > >>> > >>> On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis > >>> wrote: > >>>> I think that Clojure should switch to a better license with similar > >>>> spirit > >>>> like Apache 2.0, BSD, or MIT. > >>>> While the EPL doesn't have the evil "copyleft" requirement of GPL, and > >>>> therefore allows and encourages commercial uses of the code, it has a > >>>> requirement that makes it incompatible with the GPL: If you create > >>>> modified > >>>> versions of EPL-covered software, you must slap your name (or any other > >>>> identity) on it. In my humble opinion, this restriction isn't justified. > >>>> (All, or most, creators of modified versions will do that anyway). It may > >>>> have been chosen uncarefully. Other permissive licenses better fulfill > >>>> Rich > >>>> Hickey's spirit. > >> > >> -- > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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/groups/opt_out. > > > > -- > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from th
Re: eclipse (counterclockwise) questions
I rarely use debug mode even when we had a mix of Clojure/Java code a year ago. When it happens it's because some obscure compiler error made me bang my head on my desk several times :) Never tried debug mode with java source code changes to see how far we can go with on the fly compilation, to me the words dynamic and Java are mutually exclusive :) If you cannot change method signatures, this usage looks quite limited. Luc P. > On c), it is worth noting that if you run the REPL in Eclipse's debug mode > then you can change Java source code without restarting the REPL in many > cases. It will do hot code reloading of Java method bodies just fine. The > only thing you can't do is change method signatures, which requires a full > JVM restart I think. > > On Monday, 16 September 2013 01:13:21 UTC+8, Luc wrote: > > > > a) You test your code using the REPL window. In the bottom there's a user > > input > > area were you can run Clojure expression interactively. > > The REPL panel has a couple of buttons in the top right corner. > > You can see the last exception, interrupt processing if it loops > > forever, ... > > > > The console is used to look at detailed error messages from the > > runtime > > like exceptions. > > > > b) When editing a Clojure source file, you can load it in a REPL directly > > by using either a shortcut ctrl->alt->s or through the > > mouse-right-click -> Clojure > > menu. Look at the shortcuts available. You can reload a name space > > in a running REPL on the fly, redefine stuff through cursor selection, > > change the current name space in the REPL to the one of the source > > file > > edited, > > > > c) The time it takes to get the REPL alive can be significant depending on > > your > > hardware. The idea is to avoid restarting it as much as possible by > > reloading name spaces or redefining fns, ... w/o shutting down your > > current REPL. Beware that in some cases it's unavoidable like when > > you alter the project class path or if you are modifying java source > > code > > part of your clojure project. The Java compilation will alter static > > files > > not the loaded code in the JVM supporting the REPL. > > > > Can't help you much with the menu that vanished but if you work > > within a clojure source file and not the other way around, you should be > > able > > to run it with the above indications. > > > > Make sure that your project has it's Clojure nature enabled otherwise none > > of > > the Clojure shortcuts will appear in the editor context menu. > > > > Luc > > > > > > > > > > > > > I'm learning clojure on eclipse (counterclockwise plugin). > > > > > >- When I click "run" in eclipse (as I would do with Java) I get not > > only > > >the console opened but this "REPL" window. Why is it necessary and > > what > > >does it do? > > >- When I click "run" it takes quite a few seconds to launch the app. > > Is > > >there a way to make it faster? > > >- When I need to edit the code and relaunch (run) the the app I'm > > >getting this message: "The selection cannot be launched, and there > > are no > > >recent launches". What is that and why wouldn't it let me relaunch my > > code? > > >If I wait a while I can launch it again. > > >- I was screwing around and I don't know what I did, but now "Run as" > > -> > > >"Clojure Application" option is gone. How do I get it back? > > > > > > This is simple bit of code that I'm trying to run: > > > > > > (ns ClojureTest.core) > > > (let [input (read-line)] > > > (if (= "x" input) > > > (do > > > (println "Exit") > > > (System/exit 0) > > > ) > > > (do > > > (println input) > > > (recur) > > > ) > > > )) > > > > > > -- > > > -- > > > 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 >
Re: eclipse (counterclockwise) questions
a) You test your code using the REPL window. In the bottom there's a user input area were you can run Clojure expression interactively. The REPL panel has a couple of buttons in the top right corner. You can see the last exception, interrupt processing if it loops forever, ... The console is used to look at detailed error messages from the runtime like exceptions. b) When editing a Clojure source file, you can load it in a REPL directly by using either a shortcut ctrl->alt->s or through the mouse-right-click -> Clojure menu. Look at the shortcuts available. You can reload a name space in a running REPL on the fly, redefine stuff through cursor selection, change the current name space in the REPL to the one of the source file edited, c) The time it takes to get the REPL alive can be significant depending on your hardware. The idea is to avoid restarting it as much as possible by reloading name spaces or redefining fns, ... w/o shutting down your current REPL. Beware that in some cases it's unavoidable like when you alter the project class path or if you are modifying java source code part of your clojure project. The Java compilation will alter static files not the loaded code in the JVM supporting the REPL. Can't help you much with the menu that vanished but if you work within a clojure source file and not the other way around, you should be able to run it with the above indications. Make sure that your project has it's Clojure nature enabled otherwise none of the Clojure shortcuts will appear in the editor context menu. Luc > > > I'm learning clojure on eclipse (counterclockwise plugin). > >- When I click "run" in eclipse (as I would do with Java) I get not only >the console opened but this "REPL" window. Why is it necessary and what >does it do? >- When I click "run" it takes quite a few seconds to launch the app. Is >there a way to make it faster? >- When I need to edit the code and relaunch (run) the the app I'm >getting this message: "The selection cannot be launched, and there are no >recent launches". What is that and why wouldn't it let me relaunch my > code? >If I wait a while I can launch it again. >- I was screwing around and I don't know what I did, but now "Run as" -> >"Clojure Application" option is gone. How do I get it back? > > This is simple bit of code that I'm trying to run: > > (ns ClojureTest.core) > (let [input (read-line)] > (if (= "x" input) > (do > (println "Exit") > (System/exit 0) > ) > (do > (println input) > (recur) > ) > )) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
t;> years we will have only doubles and longs on GPUs... do you believe in it? > >> Why we need them there at all? > >> > >> I still strongly believe that primitives support should be made one of > >> the highest priorities to support. > >> > >> Lets look from a perspective of someone who researches the language, > >> considering if to adhere to it. Here is a couple of frustrations that hit > >> me so much that I think could even diverse somone from using the language. > >> Warning: the following three points may cause rage in some individuals > >> (they do cause a rage in me at least, because I really like Clojure) : > >> > >> 1) Clojure is said to be "data-oriented". Rich Hickey says that in the > >> videos. Cool! I have a stream of millions floats and ints to be processed > >> on the fly! Now we find that it is not data-oriented. It is double, long > >> and Object oriented. Data does not just come as "information" it comes with > >> its data-type. Bending data-sources and data-consumers to your will usually > >> does not sign a good data-processing. > >> 2) Clojure is said to make simple things easy. Alright, that's a PC in > >> front of me? With a JVM? Alright, I want to add,multiply, divide and > >> subtract some billion floats. What could be simpler?... Uh... typehints.. > >> alright, sure JVM is typed, we have types in Java and Scala, that's ok! Oh, > >> only local... oh, still always returns doubles... err.. boxed? Cast? Oh... > >> 3) As Mikera pointed out, some libraries, like "fast arrays on Clojure" > >> is just.. a little bit too much. Are they faster than Java arrays? A > >> library that implements fast arrays for a language that runs on a VM that > >> has fast arrays? For a language, claimed to be perfect for data-processing? > >> There is nothing wrong with the library, I think it is a masterpiece, but > >> something scares me here. > >> > >> Surely, preserving semantics while letting full primitives support for > >> Clojure, as it is right now, is a challenge. I really like the symantics as > >> it is now, but the cost is too great. The examples that Timothy and Mikera > >> are discussing right now is a problem. Some my ideas, although I am not as > >> professional with them and some of them might not make sense at all > >> (sorry): > >> 1) In computations you do not often use functions that compute floats to > >> compute ints instead. Usually you know what are you computing. I wouldn't > >> switch, say spatial vector calculations from floats to ints under any > >> circumstances. Remember Java - when you write signatures of your > >> computational functions - how often do you change types? float<->double or > >> int<->long maybe, but still not likely. Even on a lisp. > >> 2) That leads to the other question - what if you *still* somehow want > >> to reuse a computational function for other types? Well, maybe you could > >> make functions named (+f) or (+i)? Or have a macros that builds them for > >> you and calls them for you? > >> 3) To simplify furhter: can a primitive typization of a function be > >> specified by some clever tag in metadata? > >> 4) Can functions working with primitives and the other functions be > >> separated? I.e. functions working with primitives only take in primitives. > >> 5) If working with primitives would introduce more burden to the user, > >> could macros help? > >> 6) To avoid the aforementioned explosion, can a functional interface, as > >> proposed, be synthesized, with some static field hint for Java to not lose > >> the interop? > >> > >> -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_ou
Re: The Eclipse Public License is not a good license
Considering that Rich himself chose the license more than 5 years ago, as you can see on github looking at files under the 1.0 tag (not counting pre 1.0 releases) and that you did not get him to lay down on a couch nearby while taking notes, I think that your assumptions about his spirit are quite wrong. Or you are insinuating that he is not in full possession of his faculties which is an unlikely possibility ? :) (joking here Rich :) If he took a year to toy with ideas and come up with Clojure, it would have been pretty sloppy to choose the wrong license and keep it as is for 5 years... no ? Luc P. > I think that Clojure should switch to a better license with similar spirit > like Apache 2.0, BSD, or MIT. > While the EPL doesn't have the evil "copyleft" requirement of GPL, and > therefore allows and encourages commercial uses of the code, it has a > requirement that makes it incompatible with the GPL: If you create modified > versions of EPL-covered software, you must slap your name (or any other > identity) on it. In my humble opinion, this restriction isn't justified. > (All, or most, creators of modified versions will do that anyway). It may > have been chosen uncarefully. Other permissive licenses better fulfill Rich > Hickey's spirit. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Functional purity and "globals" in Clojure
Euh... our local config would require loading a top level map with more than twenty keys and a dozen levels deep of maps. I am not sure I would like to carry a local copy in all workers. Freezing the app somehow when a config change occurs is mandatory. Each node in the cluster runs at least a dozen workers and not all the nodes run the same set of workers. We cannot allow a worker to run with the old config in place while others pick up the changes. Mismatches in resources between collaboration workers would create a huge chaos. Allowing some workers to continue processing would require knowing which ones are impacted by a change and which ones can safely continue w/o picking up the change. This requires a tool to analyze dependencies at runtime when a config change occurs. This may be a future enhancement but up to now the value of such an enhancement has been very low. A config change does not stall the app for a significant amount of time. Luc P. > 2013/9/11 Softaddicts : > > We load configuration data once from zookeeper and conceal it in a name > > space. > > Changing the context is quite simple, we reload resources in this name space > > using a minimal list of properties which says where the configuration data > > should be > > pulled from in zookeeper. > > > > This is doable from the REPL at any time. No other name space keeps > > this stuff in vars. Any external resource is pulled at runtime from the > > configuration name space where they are cached except for some very short > > lived > > structures (requests to storage, locks, queues, channels, ... for the > > duration of > > the request). > > > > Test configuration data is also contained in zookeeper. Tests > > pull from this configuration tree the configuration they need. > > > > Part of the test stubbing is kept in this configuration. > > > > No mutations occur in the configuration data from zookeeper during the > > "normal" > > app life cycle. We allow config changes while the app is running but in a > > special > > context of its life cycle. Namely the app has to enter a state that allows > > it to > > reconfigured itself. This means that workers have been stopped, > > > > We can test a new configuration without mutating the previous one in > > zookeeper > > using a versioning scheme. > > > > This requires some discipline enforced by the configuration name space API. > > So far it's been a charm to work with. > > Sure, and adding a binding call providing the same config as the one > found in root would allow for the whole thread to consistently read > the same value. > > > > > Luc P. > > > >> As far as possible, I think it is best to try and minimise mutable global > >> state (like mutable configuration data) and implicit context (like dynamic > >> vars). My preferred approach is to pass the configuration data (as a value) > >> to a higher order function that constructs the configurable object / > >> function appropriately. I regard this is more of a "functional" style. So > >> you might do something like: > >> > >> (def my-ring-application (create-application config-map)) > >> > >> Once constructed, the ring application is fully configured and doesn't need > >> any extra parameters, i.e. it works just like a regular ring application. > >> You can treat the ring application as being effectively immutable. If you > >> want to reconfigure, then just create a new one! > >> > >> This approach has several advantages: > >> - It's highly composable. Your components can easily be plugged together, > >> since they aren't bound to any external configuration state. > >> - You can perform some significant optimisations in the construction phase > >> (depending on the nature of the configuration you might be able to > >> eliminate validation checks, optimise the size of buffers etc.) > >> - It's highly testable. Just create as many differently-configured > >> instances as you like. > >> > >> The main downside, of course, is that you need to be thoughtful and do a > >> bit more work in designing the constructor function. But I think that's a > >> worthwhile activity - it can often lead to a better design overall. > >> > >> Note that this technique can apply to much more than web applications. You > >> can even use it to construct objects that themselves contain mutable state. > >> For example, I use this method to construct the entire GUI + running game > >> instance f
Re: Functional purity and "globals" in Clojure
wherever, just like global state. The trick is now that now you're no > >longer certain what e.g. your model functions are expecting there to be > > in > >the system and testing becomes trickier. Now you have to either lein > > test > >with a separate set of configurations (which doesn't actually give you > > much > >per-test granularity) or use with-redefs everywhere to make sure the > > right > >test config state is being used. > >- Something in the middle where perhaps you agree to never directly > >reference the configs map from your models (again, thinking MVC here) > > and > >instead only ever access it from controllers, and pass the necessary > >options along down to the model functions. This way you can test both > >controllers and models in isolation in purity. > > > > Ultimately I want to contain the chaos of having to know internal > > implementation details of my functions at different layers and want them to > > be easily testable in isolation. It does seem like the first option is the > > most straightforward, but I'd be curious to find out what those of you who > > have deal with the problem for a while would recommend. Purity all the way, > > or are there patterns that can give you the best of both worlds? Or what > > else? > > > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Functional purity and "globals" in Clojure
This presentation is funny from Stuart is interesting and funny to watch as usual :) The "mud ball" issue is not new and you can face it in other languages than Lisp that lack a single straight jacket with which anything needs to be defined (like classes). Freedom comes with a price, you cannot always rely on some fixed rail guards to tell you how to do things. I guess that a decade of OOP frenzy took its toll and now some folks suffer from vertigo when they switch to a "muddy" language :) Luc P > This Clojure/West talk deals with many of these concepts. > > http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques > > Timothy > > > On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier wrote: > > > > > > > Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc: > > > >> I agree more or less, I hate having my configuration data spread > >> everywhere. > >> I prefer to dedicate a name space to maintain/access configuration data. > >> I usually split access to resources using bundles. > >> A bundle can reflect anything you want in your design, including a > >> controller... > >> > > > > You can always use a global config system and pass through the > > configuration information into the sub systems. > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > -- > “One of the main causes of the fall of the Roman Empire was > > > > that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Functional purity and "globals" in Clojure
I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller... This allows you to later change where you store and how you manage your configuration underneath, calls to the configuration are traceable in your code (conf/...) and you can easily stub it for testing purposes. Yes you need some discipline to avoid accessing it from everywhere (it could be tempting) but in general I refer to it at the top level and pass bits of the configuration data downward. Downward in your code you refer to semantics that have little to do with what the configuration data may represent as a whole. E.g. when trying to create a socket, you do not matter where the host/port came from in your configuration, you just need the values as args. It helps keeping your functions as pure a possible or at least with a clearly delimited side effect scope and still allows tests to be written. Attaining 100% purity is in my view a nice but rarely reachable objective. I would say that 80 to 90% is more realistic :) Luc P. > Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin: > > > > >- Something in the middle where perhaps you agree to never directly > >reference the configs map from your models (again, thinking MVC here) > > and > >instead only ever access it from controllers, and pass the necessary > >options along down to the model functions. This way you can test both > >controllers and models in isolation in purity. > > > > > I'd do the following: for every layout of your application (persistence, > datamodel, web) define one or more vars that hold the configuration > specific for that layer. Testing a layer is easy and documentation of the > layer gives you the necessary information about the configuration vars. > > -billy. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: hashing binary data
Why not keep track of the hash of blocks already stored and discard
duplicates blocks from memory asap ?
I am talking here of keeping blocks as Clojure structures so the hash will be
consistent between two identical blocks.
Do you store them away as soon as you can ? Or are you trying to keep them
around somehow in memory ?
Luc
> I'm loading data files of about 1-2G, which are composed of a bunch of
> numeric data blocks. I need to store the data blocks w/o storing
> duplicates. They arrive as vectors of floats, and are stored as primitive
> byte arrays.
>
> I first tried memoizing the function that saves a block (returning an id),
> with the core memoize function. This failed because every block became a
> different key in the memoization, regardless of the content. It looks like
> clojure treats variables referencing primitive arrays as equal only if they
> refer to the same array. Note:
>
> cavm.core=> ({[1 2 3] "foo"} [1 2 3])
> "foo"
> cavm.core=> ({(float-array [1 2 3]) "foo"} (float-array [1 2 3]))
> nil
> cavm.core=> (let [a (float-array [1 2 3])] ({a "foo"} a))
> "foo"
>
>
>
> I next tried memoizing over the vector of floats, however performance
> became pathologically slow, and the process threw an OOM. I'm guessing this
> is due to the memory requirements of a clojure vector of floats vs. a
> primitive array of bytes holding the same data. Is there an easy way to
> compare the storage requirements?
>
> Any suggestions on how better to handle this?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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/groups/opt_out.
>
--
Softaddicts sent by ibisMail from my ipad!
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/groups/opt_out.
Re: core.async - handling nils
+1 We built a distributed software sending/receiving *messages* based on different protocols. All our protocols wrap data in an envelope. The receiver can then decide how to handle the message based on the envelope. Obviously, nil makes a bad envelope. A nil message on a channel never had any significance to us four years ago and rethinking about it we reach the same conclusion today :) Luc P. > On Tue, Aug 27, 2013 at 10:51 AM, Mike Anderson < > mike.r.anderson...@gmail.com> wrote: > > > To me it's all about consistency with other Clojure constructs. You can > > safely put nils in sequences, vectors, lists, sets etc.. nil is a valid > > "value" just like anything else. So why can't you put them in a channel? > > > > Channels are *not* data structures nor are they a "place" to put something. > > > > a) what if you want to send a sequence through a channel? Since nil as a > > value represents the empty sequence, you have to put in some extra special > > case handling with the current core.async model. > > > > You're not going to put random sequences into channels. Channels are > conduits for meaningful messages - some well considered coordination > protocol. > > > > Both of these, I think, are reasonable and common enough use cases that > > it's worth supporting them elegantly rather than forcing users to implement > > their own nil-wrapping functionality. > > > > If you're putting arbitrary sequences into a channel and need to wrap nils, > you probably need to redesign your coordination protocol. > > David > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: ANN clojure.trace.tools 0.7.6
Yep... I meant to type clojure/tools.trace. It's Friday, I feel thirsty, I type too fast on my iPad and I am presently visualizing a cold dripping glass full of brown beer... Will get some in a few minutes to lessen the typo errors :) Have a nice week-end, Luc P. > Assuming you meant clojure.tools.trace: > https://github.com/clojure/tools.trace, right? > > On Friday, August 23, 2013 at 1:20 PM, Softaddicts wrote: > > > Hi all, > > > > release 0.7.6 is out. It fixes crashes when trace-form(s) encounters a > > throwable without a string based constructor. > > > > This made Clojure asserts crash the tracing tool but other Java throwables > > could > > also make trace-form(s) crash. > > > > When doable more information is returned for these odd cases if a > > message string can be provided somehow in the cloned throwable. > > > > Otherwise, no tracing output is generated. > > > > This follows a report from a non contributor about the assert crash but the > > code > > fix now covers all cases to make sure that the tracing tool remains > > unobtrusive. > > > > Available from Maven in the usual fashion. > > > > Comments/questions welcomed as usual. > > > > Luc P. > > > > -- > > Softaddicts > (mailto:lprefonta...@softaddicts.ca)> sent by ibisMail from my ipad! > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > (mailto:clojure@googlegroups.com) > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > (mailto:clojure+unsubscr...@googlegroups.com) > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To 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/groups/opt_out. > > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
ANN clojure.trace.tools 0.7.6
Hi all, release 0.7.6 is out. It fixes crashes when trace-form(s) encounters a throwable without a string based constructor. This made Clojure asserts crash the tracing tool but other Java throwables could also make trace-form(s) crash. When doable more information is returned for these odd cases if a message string can be provided somehow in the cloned throwable. Otherwise, no tracing output is generated. This follows a report from a non contributor about the assert crash but the code fix now covers all cases to make sure that the tracing tool remains unobtrusive. Available from Maven in the usual fashion. Comments/questions welcomed as usual. Luc P. -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: problem with edn
This brings an interesting twist... I am used to build polyglot solutions, our project has been a mix of Java, Ruby and Clojure for a year and a half and prior to that I would mix languages in a project on the fly. However I am not in a mood these days to sacrifice features available in Clojure to bend to other languages to comply with their poor feature set given the challenges we are facing in our domain. If you can own both ends, do it in Clojure exploiting all it's features and provide poor man's API to other languages as required. This may require implementing some custom front end logic within these APIs that have little to do with the internal representation used elsewhere. Being agnostic to do a "favor" to other languages maybe unavoidable in some situations but it may impact your design decisions, you could cripple your mental processes by avoiding using features not available in every language involved. Being polyglot was a necessity to me before Clojure/ClojureScript got most of the platforms covered. It's not to me an advantage anymore to write polyglot solutions. Reducing to common language features to me = dragging your feet on the rug while you could be running faster than Usain Bolt. Luc > Hi Luc, > > Le jeudi 22 août 2013 21:19:00 UTC+2, Luc a écrit : > > > > > > > > Metadata is part of the Clojure environment and part of the value domain > > > > it handles. > > Why should it not be transmitted along with the value ? > > > > If the receiver is not written in Clojure it may be questionable an > > > > probably not > > very useful to transmit it but otherwise ? > > > > All you're saying is right, as long as you own your data and communicate > > > between clojure programs, any "hack" is just particular design solution -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: problem with edn
I disagree... strongly. The value domain I am referring to is the one covered by your application, customized metadata is of little value elsewhere obviously. In typed languages the container defines a lot about what can be done with a value and what is forbidden. Nobody would try to rely on the raw value to guess these things in a typed language. The container is used for this purpose. Raw values are useless without their container even more when it is composed to create complex types. Data types are defined against your app. domain to carry values. When you serialize in Java and send data on the wire, the data type is included, and you need to have the same version available on both ends. Using RPCs, you end up with the same requirement whether in C, Java, because data has to be serialized against it's container definition which have to be agreed to by both ends. No mismatches are tolerated. The fact that many other languages do not support something as dynamic as metadata does not mean that metadata is not an integral part of your domain values. It merely says that these typed languages rely a lot on the data containers to carry similar information that could be also carried by metadata and have no or little need for dynamic metadata. They however lack the flexibility that metadata offers. It can be generated dynamically, it can evolve without impacting other processing steps. Metadata has no impact on values, which allows values to be exchanged even when the other party is unaware that additions have been made to the metadata for other purposes. Contrary to RPCs, native serialization, ... where a single slight change requires you to upgrade everyone to the new definition. Saying that metadata should not be transmitted over the wire is restrictive and unjustified when you compare with the alternatives. I suspect that too few people have been using meta data customized to their app and that many see it has an internal feature restricted to the Clojure runtime and other exotic uses. Luc P. > On Aug 22, 2013 2:19 PM, "Softaddicts" wrote: > > > > > > > > > > > Jim, > > > > This is indeed a hack and not a best practice, maybe you're not using > the > right tool for your problem... > > > > - If you want to exchange data (think values), you should not be in > need of > keeping types and meta data > > > > Metadata is part of the Clojure environment and part of the value domain > it handles. > > Why should it not be transmitted along with the value ? > > If the receiver is not written in Clojure it may be questionable an > probably not > > very useful to transmit it but otherwise ? > > I don't think anyone suggested the type of a record should not be part of > its edn representation. Here we're talking about arbitrary metadata. While > it is "part of the Clojure environment," the way in which it's "part of the > value domain it handles" is... subtle. > > "An important thing to understand about metadata is that it is not > considered to be part of the value of an object. As such, metadata does not > impact equality (or hash codes). Two objects that differ only in metadata > are equal." > http://clojure.org/metadata > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: problem with edn
> Jim,
> > This is indeed a hack and not a best practice, maybe you're not using the >
> > right tool for your problem...
> > - If you want to exchange data (think values), you should not be in need of
> > > keeping types and meta data
Metadata is part of the Clojure environment and part of the value domain it
handles.
Why should it not be transmitted along with the value ?
If the receiver is not written in Clojure it may be questionable an probably not
very useful to transmit it but otherwise ?
> when you exchange data in json, for example, you're not providing object >
> class in the stream
What's an array then in Json ? Somehow it has to end up in a concrete type.
If both ends are written in Clojure, why not convey the type ? What harm can it
do ?
Records are essentially immutable maps. I would carry the type of record as
metadata and let the other end decide to instantiate it or not under the given
record type. This is a personal choice based on the context (same app at both
ends or maybe not, ...).
Again if the receiver is not written in Clojure obviously it does not make
sense but if read the OP post correctly, it's not the case.
> > - If you just want serialization to reload hot data or use some kind of RPC
> > > mechanism over the wire, than I think edn is not the right tool.
>
Uh ? "hot data" ? Here we exchange thousands of messages per hour using
Edn. We care little that the data is cold, medium or hot. It simply works..
Configuration data, live data,..
We added a few extensions to support some objects as is but very little.
RPC stuff is hard to work with and couples both ends a lot. Edn is much more
flexible by allowing you to decide when and how you want to instantiate
concrete implementations.
Any (easier) alternative you can come with ?
Luc P.
> > Cheers
> > Le jeudi 22 août 2013 13:24:33 UTC+2, Jim foo.bar a écrit :
> >
> > Hi Meikel,
> >
> > this is funny! I thought about this approach but I originally considered >
> > > it to be a clever hack rather than the official way to do this...Since I
> > > > can't test it yet with my record , I hope you don't mind me asking
> > another > > question...
> >
> > there is no need for print-dup bound to true here, right?
> >
> > thanks a lot for your time :)
> >
> > Jim
> >
> >
> > On 22/08/13 12:00, Meikel Brandmeyer (kotarak) wrote:
> > > > (defmethod print-method Foo
> > [foo ^Writer w]
> > (.write w "#my/foo ")
> > (print-method {:a (:a foo) :b (:b foo) :c (:c foo) :meta (meta foo)} w))
> >
> > (defn foo-reader
> > [foo-data]
> > (with-meta (map->Foo (dissoc foo-data :meta)) (:meta foo-data)))
> >
> > Read with:
> >
> > (edn/read {'my/foo foo-reader} ...)
> >
> > Printing might be optimised a bit. And the :meta key could be made more > >
> > robust. (records may contain arbitrary keys.)
> >
> >
> > > > -- > -- > You received this message because you are subscribed to the
> > > > Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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/groups/opt_out.
> --
Softaddicts sent by ibisMail from my ipad!
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/groups/opt_out.
Re: tools for minimizing forward declaration
REPL versus compilation in Lisp have for many decades been two different things. In the REPL, you were allowed to refer to symbols that were undefined in the current lexical scope, hoping that at runtime they would eventually exists some where on the stack. To compile such code you needed to add declarations for this stuff not in the lexical scope of the compiler to tell it that it would be defined later else where. Either later in the same file or in a different one, this did not matter. Otherwise the compiler would simply fail. Compilation was an odd thing in Lisp initially and it was sufficiently different from the REPL to require twists in your code when you wanted to compile it. It was seen as a second step, after dev had been done in the REPL. The REPL is there to swallow forms which are unrelated. The kind of compilation you would like to see requires something more (the "file approach ?"). If we fall too much on the "compilation/optimization" side, then this relative independence of forms will eventually break and create it's own set of problems at the REPL. Yes Lisps were designed mainly for REPL interaction, compiling came afterward. I was a witness of this era mainly because I am a dinosaur :) Clojure's approach is somewhere closer to the compilation side in view of the requirements of it's supporting container but I do not think that it can get much closer without breaking some of that dynamic REPL stuff that speeds up development and that we like. Luc P. > Tim Visher writes: > > > On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas > > wrote: > >>> I'll point out as well that though I thought Yegge's criticisms of > >>> Clojure were a bit polemical (I guess that's his style), the single > >>> pass compiler issue was one of his biggest gripes, and I do think it > >>> still rings true. I feel like I have to babysit clojure in this > >>> regard, when I usually feel like clojure is babysitting me! :) > >> > >> Have you seen this? https://news.ycombinator.com/item?id=2467359 > > > > That's what I was referring to. Was there something specific about it > > that you wanted to call out? :) > > > Actually, that's quite interesting, and I hadn't seen it before. > > I can understand the reasons why forward declaration makes the > implementation of clojure easy, but it does seem to be pushing the > burden onto the programmer, rather than the language designer. I'm > particularly not convinced by the argument that "Lisps were designed to > receive a set of interactions/forms via a REPL"; forward declaration > introduces another circumstance where the state of your REPL can get in > a twist: your source might look like this... > > (def y) > (defn x[] y) > > then get changed to > > (defn x[] y) > (def y) > > and working quite happily *until* you restart the REPL. Re-starting just > in case is a problem with most REPLs, and this doesn't help. On the > whole, I think I prefer compile warnings, rather than everything > breaking. > > I seem to have stirred up a bit of a nest. > > 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Storing Clojure code in a data store
We store code/data in zookeeper and riak. We serialize these using nippy. You can get notified on changes using zookeeper watchers on the nodes storing either children changes or changes to the node data as you wish. We are highly satisfied with this, we also store configuration data in zookeeper. We use clj-zookeeper directly. You can also have a look at avout, it implements locks, shared atoms, ... This may shield you from some zookeeper implementation details. We stayed away from avout mainly because we have strict performance real time requirements to meet. It's easier for us to monitor these through our own thin code layers wrapping specific semantics and decide were we want to store stuff (zookeeper or riak or as a combo). We run on clusters of small to server grade computers and needed a zero maintenance scalable solution. With bigger backbones and the kind of use you have in mind, I would look at avout first. Beware that zookeeper has a 1mbytes data size limit per node and I do not think that avout circumvent this limit. This may impact you or not depending on the size of what you intend to store. We implemented an overspill to a riak bucket in some of our abstractions to overcome this limit while keeping the anchor in the zookeeper node space. Since riak is also cluster aware it runs everywhere as zookeeper, it does not impact us maintenance wise other than a job we run from time to time to see if discrepancies appear over time between a zookeeper parent node children and the key/value stored in the corresponding riak bucket. You could also chunk data as zookeeper sequential nodes under a root node and concatenate their data chunks back together. If there is no high usage of this feature it will be acceptable performance wise. Initially we implemented queues like this on top of zookeeper and performed reasonably well for our needs. Hope this helps, Luc P. > Hi, > > I'm wondering what approaches people take if they want to have Clojure code > loaded at runtime from some data store. > > We operate a large website and I'd like the ability to deploy our mustache > templates & immediate corresponding clojure code at will, rolling back etc > if need be, without having to redeploy the host application. > > I'm interested in what a potential dev process would look like, i.e. I > still want the Clojure files on the local file system editable in Emacs > (maybe through git submodules). I'm thinking the solution is to have a > command line tool / build process that uploads a targeted module (template > + Clojure code) into the data store (i.e. using Avout on ZooKeeper, or > Datomic, whatever) and the main running application is notified that > something has changed. We would then have a small management app on top of > this where you can roll back between different revisions of the modules. > > Not looking to reinvent any wheels here, more wondering what others have > done, > > 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Do you like the Clojure syntax?
pay > >> all in the same week every week... and bouncing among all three makes > >> getting comfortable with Clojure a little slow. Further, I fear (deeply... > >> in my bones) that once I am comfortable with Clojure, doing Scala will be > >> as disgusting as doing Java is after 7 years of Scala. :-( > >> > >> > >> > >> On Mon, Aug 12, 2013 at 12:52 AM, Răzvan Rotaru > >> wrote: > >> > >>> Hi, > >>> > >>> I'm curious about the general opinion on the Clojure syntax, whether > >>> people actually like it or just use it because it provides macros. So I > >>> would like to ask you to participate in a poll. Thank You. > >>> > >>> Here's the link: > >>> > >>> https://docs.google.com/forms/d/1GSgfkeThpUYlgFVzhhNIgA1JbTilu6S9eudq_Sbxl34/viewform > >>> > >>> Răzvan > >>> > >>> -- > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Clojure" group. > >>> To post to this group, send email to clojure@googlegroups.com > >>> Note that posts from new members are moderated - please be patient with > >>> your first post. > >>> To unsubscribe from 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/groups/opt_out. > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Telegram, Simply Beautiful CMS https://telegr.am > >> Lift, the simply functional web framework http://liftweb.net > >> Follow me: http://twitter.com/dpp > >> Blog: http://goodstuff.im > >> > >> -- > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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/groups/opt_out. > >> > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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
Re: Do you like the Clojure syntax?
> Follow me: http://twitter.com/dpp > Blog: http://goodstuff.im > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Do you like the Clojure syntax?
isolating the syntax from the other features of the language is a like removing a part from a rocket engine however small it may be and wondering if it will lift off without it. Macros are the first thing you may think of related to syntax change I am convinced that other areas benefit from the syntax. It's early here and without caffein I will not even attempt to make a list.. Who would choose a tool based on its syntax alone ? A tool = feature set = more or less productivity. We're not in a grocery store choosing between a banana and a cauliflower based on their respective color to accompany a steak. Banana + steak ? Wow... maybe some chef tried it or will but personally I pass, as good looking as the banana might be :) It's like emacs to me (joking here guys :) Your poll has only two questions, I would have added at least a third one, how many programming languages have you been using at work ? Maybe a fourth one, for how many years have you been programming ? How much weight does the first answer have if you do not assess the comparison basis of people answering the first question ? I would probably drop the second one. A pool looks like a simple tool but it's hard work to put together questions to get meaningful data. Luc P. > Hi, > > I'm curious about the general opinion on the Clojure syntax, whether people > > > actually like it or just use it because it provides macros. So I would > > like > to ask you to participate in a poll. Thank You. > > Here's the link: https://docs.google.com/forms/d/1GSgfkeThpUYlgFVzhhNIgA1JbTilu6S9eudq_Sbxl34/viewform > > Răzvan > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: apply inc
How many args does inc supports ? Only one. (apply inc [ 1 3 ]) is the same as (inc 1 3) which would also trigger an arity exception. apply does not call the given fn on each item in the collection it's given, it calls it once with the whole collection as the argument list. (map inc [1 3]) calls inc on every item in the vector and would return (2 4). Hope it's clear. Luc P. > Hi there: > > Why does > > (apply str [2 3]) work > > and not > > (apply inc [4 5]) > > though > > (apply inc [4]) > > does work? > > > 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: [Proposal] Simplified 'ns' declaration
that wildcards make it "easy" (in the nearness sense), but > > > >> from a long-term maintainability standpoint, I'd prefer to have > > > >> explicit imports as is. When I'm reading your code a year from now > > > >> and need to look-up the docs on a class, wildcards make me (and anyone > > > >> else in the future) have to do that look-up every time. It's almost > > > >> the same argument as to why (:use) is a bad idea--you're dumping a > > > >> bunch of symbols into your namespace. So, you're trading some upfront > > > >> ease for some long-term simplicity. > >> > >> Yes, lots of Java tutorials are of no help in this endeavor :( > >> > >> (Again, see the parallel in the Clojure world with so much "getting > >> > >> started/example" code showing :use instead of :require). > >> > >> -Curtis > >> > >> > >> The argument for wildcards is very simple. Go to just about any > >> > >> > >> Java tutorial, for example: > >> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java > >> > >> The sample code starts off with a dozen wildcard imports. If I want > >> > >> to try to use these techniques in Clojure, I have absolutely no idea > >> > >> which specific classes to require. This creates a tremendous > >> > >> obstacle to consuming Java libraries. This has affected me > >> > >> personally on several occasions, preventing me from successfully > >> > >> figuring out how to use some Java library from Clojure. > >> > >> Maybe it's not ideal if Clojure has to walk the classpath, but the > >> > >> alternative is that I have to manually walk the classpath and jars > >> > >> myself with no idea what I'm looking for. Surely it's better for > >> > >> this to be handled through an automated 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/groups/opt_out. > >> > >> > > > > > > > > > > -- > > “One of the main causes of the fall of > >> the Roman Empire was that–lacking zero–they had no way to indicate > >> successful termination of their C programs.” > > (Robert Firth) > > > > -- > > -- > > You received this message because you are subscribed to > > > > the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
I agree on this, just started to replace some :use by refer all and I have to maintain the convention to place these at the end of the :require list otherwise they get obfuscated if they end up in the middle. There are only one or two per name space and we can have six to a dozen required name spaces with aliases in our name spaces. :use is much more obvious. we usually place them after the :require section and they can not be missed by a reader. I can live with this but not really convinced that it improves readability. Still debatable. Luc. > I find that having both `:use` and `:require` in my `ns` declarations can, > with a little judicious formatting, communicate something about which > packages are core and which are peripheral. Having to obfuscate that > distinction with a `:refer :all` tacked - in a visually obscure way - onto > `:require` forms would make me sad. Not wildly sad, but wistfully sad that > people would prefer a breaking change to simply avoiding something they don't > want to use. > > Or: > > On Aug 5, 2013, at 11:48 AM, Lee Spector wrote: > > > My point is just that the needs and priorities are diverse, and I wish > > people wouldn't be so enthusiastic about deprecating features that are > > valued by others in the community. > > > Latest book: /Functional Programming for the Object-Oriented Programmer/ > https://leanpub.com/fp-oo > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
You did not get a warning that "symbol" was overriding the core symbol fn ? Luc P. > Yesterday, I spent hours trying to figure out why some code didn't work. > The code is like so: > (defn replace-symbol-in-ast-node [old new ast] > (tree-replace (symbol old) (symbol new) ast)) > > I use tree-replace directly like this: > (ast/tree-replace (symbol 'a) (symbol 'c) (ast/sexp->parsley '(+ a b))) > > I thought the result would the the same but I was wrong. After hours of > thinking, I finally figured it out. > Guess what? The 'symbol' function in the first code snippet is not the > standard 'symbol'. It actually is: > (defn symbol [sym] > (make-node :atom (core/vector (name sym > > It's defined in another library. But I stupidly thought it was the standard > 'symbol'. > Part of this was my fault, I guess. I shouldn't have taken it for granted > and guessed its meaning. But who know? > In my opinion if we use less :use, it would easier for others to read our > code and less likely to misunderstand the meaning, or at least *Do Not Use > *those > standard names*.* > > > On Wednesday, July 24, 2013 1:50:50 AM UTC+10, Greg wrote: > > > > I think I read somewhere that :use is no longer encouraged, but I could be > > mistaken. > > > > From what I've read, it seems like most people agree that Clojure has too > > many ways of including/importing/referencing/requiring/using things: > > > > > > http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html > > > > > > The above gives a very nice explanation of all the various difference, but > > it also acknowledges their complexity. > > > > Since :use uses :require, and since :require can do everything that :use > > can, can we simplify Clojure programming a bit for newcomers by deprecating > > the use of :use? The situation in ClojureScript is even worse because it > > adds :require-macros on top of all the other ways of including files. > > > > Ideally, it would be awesome if there was just a single directive for > > everything, but perhaps there's some complicated low-level reason why > > that's not possible. :-\ > > > > Thoughts? > > > > Thanks, > > Greg > > > > P.S. If this has already been brought up you have my sincere apologies. > > > > -- > > Please do not email me anything that you are not comfortable also sharing > > with the NSA. > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Status of Generic Functions (a la lisp)
I can't understand why multi methods or protocols do not satisfy your needs. Care to shed some light on your needs ? Luc P. > Hi, > > I'm looking for fast lisp style generic functions in clojure. In other > words: multimethods that dispatch on the java type. > A search on the web revealed little, since protocols and multimethods > > always show up. I have also seen some old discussion in this group on the > > topic, but I couldn't figure out whether there is a usable implementation > > out there. So I'm posting my question on this group. > > 1/ Is there generic function implementation out there that I can use? > 2/ > > Are there plans to include them in future versions of clojure? > 3/ And > > lastly, could this be implemented as a sequence of single dispatch > (using > > the available single dispatch, which is fast)? > > Thanks, > Răzvan > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
I do the same but it's because of my age and failing memory, glad that some younger folks face the same issue :) Luc P. > On Friday, July 26, 2013 10:30:04 AM UTC-7, greenh wrote: > > Finally, with respect to the “it’s too hard for newcomers” line of > > > argumentation, > > my reaction is: this is silly. Do you *really* want to optimize Clojure > > > for use by newcomers? > > The original complaint was not that it's too hard for newcomers, it was was > > > that Rich Hickey was saying every time he had to create a new namespace > > he > couldn't remember how it worked and had to go copy from an existing > > example. > > -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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
Too much is the same as not enough. People can choose to which extend they want to hang themselves, how thick the rope they "use" should be and the height from which they will throw themselves to insure a fast and painless deliverance, hopefully by breaking their neck as fast as possible :) There is significant risk to get hit by a car if you cross on foot a highway yet in some countries people do this daily. Why bother about it ? You could preach about safety for years in these countries without seeing a noticeable change. Live and let die... Personal tastes are just that... personal tastes. Context should prevail over any dogma == pragmatism. Luc P. > Imo, as soon as you have to maintain other peoples' code that heavily uses > naked use, require starts to look a whole lot nicer. > > On Wed, Jul 24, 2013 at 10:14 AM, Lee Spector wrote: > > > > > On Jul 24, 2013, at 12:45 PM, dennis zhuang wrote: > > > I am using ':use' for my own namespaces.I know it's discouraged, but if > > i can control my own code,why not? Compiler can give me warnings and i > > process all warnings carefully. > > > > I agree. But I do now see that it's really just about as good, and better > > for other reasons, to use :require :refer :all instead. > > > > However, if the language then starts hassling me about using :require > > :refer :all then that will really rain on my parade. I don't want to have > > to jump through hoops to get different parts of my projects to see each > > other. Clojure already requires more of this than I'd prefer -- e.g. no way > > to require a whole subdirectory with a wildcard (and I understand this is > > unlikely to happen) -- and it'd be a drag to have to maintain lists of > > every function name everywhere. > > > > -Lee > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
This is quite decent. Luc > I can confirm that the point of adding :refer support to :require was to > deprecate :use; I suggested this to Rich at the 2011 Conj when he mentioned > the ns macro is too complicated, and he agreed it would be a good idea to > enhance :require so that it would make :use unnecessary in order to reduce > conceptual overhead. I submitted a patch, and it was applied for 1.4.0. > > As far as I recall, this discussion was only around :use clauses in the ns > macro. I think the clojure.core/use function is still very useful in the > repl for things like tracing and pprint and don't foresee it going anywhere. > > My assumption from our discussion would be that a warning would be added in > a near release when :use was detected in the ns macro, and that it would be > removed for Clojure 2.0 when backwards-incompatible changes are OK. But > that's just my own guess; I don't know if Rich has any plans to do this. > > -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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
I disagree, when I use tracing fns and other useful REPL tools, I like to have them included without having to prefix them with an alias. It's not a hack it's a feature and you are free to use it or not. If code writers do not care about code readers it's a choice, maybe bad but that decision is not yours to take. It's theirs in their own context. Now this thread has slowly shifted to "can we streamline how we express this feature" to "lets forbid this feature to be used". If ends up creating such "policies" enforced by the language, it's the wrong route. My answer to such proposals is a definite "no". This a red line to me that should not be crossed. Luc P. > > I hate it mainly in blogs, where they explain some new API. They :use > like 3 namespaces and you have to guess which fn is from which ns :) > > Agree. > Code is read much more often than it is written, so omitting a few > character is not effective time-saving. > I also don't like :refer :all. > I think it should be considered hack rather than official feature. > > On Wednesday, July 24, 2013 3:17:02 AM UTC+9, Jozef Wagner wrote: > > > > +1, :use is IMO an antipattern. > > > > I hate it mainly in blogs, where they explain some new API. They :use like > > 3 namespaces and you have to guess which fn is from which ns :) > > > > JW > > > > On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: > >> > >> I think I read somewhere that :use is no longer encouraged, but I could > >> be mistaken. > >> > >> From what I've read, it seems like most people agree that Clojure has too > >> many ways of including/importing/referencing/requiring/using things: > >> > >> > >> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html > >> > >> > >> The above gives a very nice explanation of all the various difference, > >> but it also acknowledges their complexity. > >> > >> Since :use uses :require, and since :require can do everything that :use > >> can, can we simplify Clojure programming a bit for newcomers by > >> deprecating > >> the use of :use? The situation in ClojureScript is even worse because it > >> adds :require-macros on top of all the other ways of including files. > >> > >> Ideally, it would be awesome if there was just a single directive for > >> everything, but perhaps there's some complicated low-level reason why > >> that's not possible. :-\ > >> > >> Thoughts? > >> > >> Thanks, > >> Greg > >> > >> P.S. If this has already been brought up you have my sincere apologies. > >> > >> -- > >> Please do not email me anything that you are not comfortable also sharing > >> with the NSA. > >> > >> > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
Maybe we need an simpler alternative to the ns macro without all these complex options :) With a short name like ns-stop-banging-your-head-on-the-wall :) Or the reverse, ns-make-your-life-more-chaotic... :) Luc P. > It's not as if *some* (cough cough) parts of Clojure were'nt > opinionated, right? :-) > > Having in the (ns) macro the possibility to use :use, to use :require, > to use :refer-clojure, to use :require-macros can be daunting, and not > only for newcomers! > > And not to mention that the vast majority of the docstring for ns > talks about :gen-class defaults ! > > And all this choice for only historical reasons is not opinionated > enough for my taste! > > I'd be willing too, to deprecate a couple things: > > :use :all in favor of :require :all > :use :only in favor of :require :only > > Let's be opinionated! :-D > > I think that's the only subset that has a chance to pass without > having to gather a commitee at the next Clojure-conj ;-) > > > 2013/7/23 Softaddicts : > > None of what has been said so far makes me believe that our usage of > > "use" is "bad". It's like a rope, you can use it for useful purposes or you > > can > > hang yourself. You use it at your own taste and will. > > > > Lack of discipline does not constitute for me a reason to trash a feature > > as scarce > > as his usefulness seems to be. > > > > :refer :all can be used as badly as :use. > > > > I am not convinced that removing a facade and leaving the feature available > > through a backdoor makes life better for anyone. :use is easily searchable > > and > > quite obvious. Not sure about spotting :refer :all in 15 name space require > > clauses. > > > > You will simply end up say "do not use refer all" instead > > of warning against using use. > > > > Gee, What a lot of "use"s in this thread :) > > > > Luc P. > > > >> One of the main issues I have faced with :use is, understanding a > >> non-trivial codebase becomes very difficult and almost always requires > >> Emacs Meta-dot. > >> > >> I'd vote for deprecating :use. > >> > >> Shantanu > >> > >> -- > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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/groups/opt_out. > >> > >> > >> > > -- > > Softaddicts sent by ibisMail from my ipad! > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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 Go
Re: Can we please deprecate the :use directive ?
None of what has been said so far makes me believe that our usage of "use" is "bad". It's like a rope, you can use it for useful purposes or you can hang yourself. You use it at your own taste and will. Lack of discipline does not constitute for me a reason to trash a feature as scarce as his usefulness seems to be. :refer :all can be used as badly as :use. I am not convinced that removing a facade and leaving the feature available through a backdoor makes life better for anyone. :use is easily searchable and quite obvious. Not sure about spotting :refer :all in 15 name space require clauses. You will simply end up say "do not use refer all" instead of warning against using use. Gee, What a lot of "use"s in this thread :) Luc P. > One of the main issues I have faced with :use is, understanding a > non-trivial codebase becomes very difficult and almost always requires > Emacs Meta-dot. > > I'd vote for deprecating :use. > > Shantanu > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Can we please deprecate the :use directive ?
We have production code using it. It's easy to say that it's a bad pattern after the fact. We have been using it in a disciplined way. It simplifies our life in the REPL we have some tools we want to see included automatically each time we switch to a name space. Anything else aside from clojure.core is required using an alias. This minimized name clashes to zero so far. This is easily spottable in the ns macro declarations and is not a source of confusion for us. We have less manipulations to do in the REPL when attaching to the live app with these "defaults" included. I do not mind about the deprecation warning as a first step. However I would like some breathing space before it gets removed entirely. It's just another to do on top of the pile of work we have these times... Luc P. > We should scour clojuresphere for uses of 'use' and automatically post > github issues to the projects of interest, and redefine the ns macro to > issue a warning with use. > > Does anyone actually like 'use'? > > Require is always more evident. > > > On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner wrote: > > > +1, :use is IMO an antipattern. > > > > I hate it mainly in blogs, where they explain some new API. They :use like > > 3 namespaces and you have to guess which fn is from which ns :) > > > > JW > > > > > > On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: > >> > >> I think I read somewhere that :use is no longer encouraged, but I could > >> be mistaken. > >> > >> From what I've read, it seems like most people agree that Clojure has too > >> many ways of including/importing/**referencing/requiring/using things: > >> > >> http://blog.8thlight.com/**colin-jones/2010/12/05/** > >> clojure-libs-and-namespaces-**require-use-import-and-ns.html<http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html> > >> > >> The above gives a very nice explanation of all the various difference, > >> but it also acknowledges their complexity. > >> > >> Since :use uses :require, and since :require can do everything that :use > >> can, can we simplify Clojure programming a bit for newcomers by deprecating > >> the use of :use? The situation in ClojureScript is even worse because it > >> adds :require-macros on top of all the other ways of including files. > >> > >> Ideally, it would be awesome if there was just a single directive for > >> everything, but perhaps there's some complicated low-level reason why > >> that's not possible. :-\ > >> > >> Thoughts? > >> > >> Thanks, > >> Greg > >> > >> P.S. If this has already been brought up you have my sincere apologies. > >> > >> -- > >> Please do not email me anything that you are not comfortable also sharing > >> with the NSA. > >> > >> -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMai
Re: primitive array casts
Type hints are given so the compiler can optimize the generated code by assuming
first that the value passed will be of the type hint.
It does not preclude you from passing something that is not what the hint says
it
should be. In this case the usual behavior is to use reflection on the value
class
to find be method and call it.
Luc P.
> Can you explain this more? In the second example, it's unhappy because a >
> vector is not a primitive array?
> > And I don't understand the idea of a "soft hint". It looks like "this may >
> > be ints", but that's true without the hint. So what is the hint doing?
> > On Saturday, July 20, 2013 2:31:50 AM UTC-7, Michał Marczyk wrote:
> >
> > Also, ^foo-style hints are "soft hints" in the following sense: > >
> > (let [^ints xs [1 2 3]] xs) ; no complaint from compiler or RTE > >
> > In contrast, ints & Co. demand that the casts be correct: > >
> > (let [xs (ints [1 2 3])] xs) ; ClassCastException > >
> >
> > On 20 July 2013 11:29, Michał Marczyk >
> > > > wrote: > > > More complete example: > > > > > > (defn get-some-ints []
> > > > > (int-array [1 2 3])) > > > > > > (set! *warn-on-reflection* true) >
> > > > > > > ;; causes a reflection warning > > > (let [xs (get-some-ints)] >
> > > > (aget xs 0)) > > > > > > ;; do not cause reflection warnings > > >
> > (let [xs (ints (get-some-ints))] > > > (aget xs 0)) > > > > > > (let [xs
> > ^ints (get-some-ints)] > > > (aget xs 0)) > > > > > > (let [^ints xs
> > (get-some-ints)] > > > (aget xs 0)) > > > > > > Cheers, > > > Michał > >
> > > > > > > > > On 20 July 2013 11:25, Michał Marczyk
> > > > > wrote: > > >> I think it's more
> > about clojure.core/{ints,longs,...}. These are > > >> basically tools for
> > removing reflection: > > >> > > >> (let [xs (ints (get-some-ints))] > > >>
> > (aget xs 0)) ; no reflection here thanks to the cast > > >> > > >>
> > Cheers, > > >> Michał > > >> > > >> > > >> On 20 July 2013 10:47, Mikera
> > > > > wrote: > > >>> Do you mean
> > something like (int-array [1 2 3 4])? > > >>> > > >>> This is a cast-like
> > operation that produces a primitive array of ints, > > >>> exactly like
> > int[] in Java. You can then use it with array operations > > like > > >>>
> > "aget". > > >>> > > >>> If you want to type-hint int-array parameters then
> > you need to use > > something > > >>> like "^ints", e.g. > > >>> > > >>>
> > (defn third-int-in-array [^ints xs] > > >>> (aget xs 2)) > > >>> > >
> > >>> On Saturday, 20 July 2013 02:28:15 UTC+1, Brian Craft wrote: > > >>>> >
> > > >>>> I'm unable to find any examples of primitive array casts, and the >
> > > docs are > > >>>> not helpful. Can someone point me to examples or docs
> > that explain > > what they > > >>>> do? > > >>> > > >>> -- > > >>> -- > >
> > >>> 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,
Re: Comma separated String values from vector
I assume here that the strings are already escaped. Which might not be true at all. pr-sr is safer in this regard but 6 times slower. Luc P. > (apply str (interpose "," (map #(str "\"" % "\"") [...]))) > > Not the most efficient way but short. > > Luc P. > > > > Hi All, > > > > I'm new to Clojure - > > > > I'm defining a vector containing string values. The requirement for me is > > to retrieve the String values separated by comma from the input vector. > > > > Example: > > > > => (def my-strings ["one" "two" "three"]) > > > > ;; My expected output should be ;; *"one", "two", "three"* > > > > I tried interpose and join as below > > > > => (apply str (interpose "," my-strings)) > > > > => (clojure.string/join "," my-strings) > > > > both returning as "one,two,three" but I need each string surrounded by > > double quotes "" like in my example example. > > > > /Sunil. > > > > > > > > > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To 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/groups/opt_out. > > > > > > > -- > Softaddicts sent by ibisMail from my ipad! > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Comma separated String values from vector
Pr-str is very slow compared to string concats Luc P. > Jay beat me to it. :) > > I'll add the documentation for pr-str: > http://clojuredocs.org/clojure_core/clojure.core/pr-str > > Jonathan > > > On Tue, Jul 16, 2013 at 4:39 PM, Jay Fields wrote: > > > this seems to do what you want: (clojure.string/join ", " (map pr-str > > my-strings)) > > > > > > On Tue, Jul 16, 2013 at 10:17 AM, Cedric Greevey wrote: > > > >> (apply str "\"" (interpose "\", \"" my-strings) "\"") might work... > >> > >> > >> On Tue, Jul 16, 2013 at 9:53 AM, wrote: > >> > >>> Hi All, > >>> > >>> I'm new to Clojure - > >>> > >>> I'm defining a vector containing string values. The requirement for me > >>> is to retrieve the String values separated by comma from the input vector. > >>> > >>> Example: > >>> > >>> => (def my-strings ["one" "two" "three"]) > >>> > >>> ;; My expected output should be ;; *"one", "two", "three"* > >>> > >>> I tried interpose and join as below > >>> > >>> => (apply str (interpose "," my-strings)) > >>> > >>> => (clojure.string/join "," my-strings) > >>> > >>> both returning as "one,two,three" but I need each string surrounded by > >>> double quotes "" like in my example example. > >>> > >>> /Sunil. > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Clojure" group. > >>> To post to this group, send email to clojure@googlegroups.com > >>> Note that posts from new members are moderated - please be patient with > >>> your first post. > >>> To unsubscribe from this group, send email to > >>> clojure+unsubscr...@googlegroups.com > >>> For more options, visit this group at > >>> http://groups.google.com/group/clojure?hl=en > >>> --- > >>> You received this message because you are subscribed to the Google > >>> Groups "Clojure" group. > >>> To 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/groups/opt_out. > >>> > >>> > >>> > >> > >> -- > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from 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/groups/opt_out. > >> > >> > >> > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > > > -- > -- > You received this message because you are subscribed to the Google &
Re: Comma separated String values from vector
(apply str (interpose "," (map #(str "\"" % "\"") [...]))) Not the most efficient way but short. Luc P. > Hi All, > > I'm new to Clojure - > > I'm defining a vector containing string values. The requirement for me is > to retrieve the String values separated by comma from the input vector. > > Example: > > => (def my-strings ["one" "two" "three"]) > > ;; My expected output should be ;; *"one", "two", "three"* > > I tried interpose and join as below > > => (apply str (interpose "," my-strings)) > > => (clojure.string/join "," my-strings) > > both returning as "one,two,three" but I need each string surrounded by > double quotes "" like in my example example. > > /Sunil. > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: [ANN]: Introducing lein-try
Nice ... try :) Luc > I figured there was a joke somewhere in there, but I just couldn't tease a > good one out ;) > On Jul 14, 2013 9:54 AM, "Softaddicts" wrote: > > > After reading this thread, I think we need another plug in to try the try > > plugin > > which in turn may fail which would trigger the need for another try plugin > > which > > > > Isn't this recursive a bit ? : > > > > Luc > > > > > > > Can you pop that in an issue on the project. In the mean time I'll see > > if I > > > reproduce that problem. > > > On Jul 13, 2013 11:30 PM, "Sean Corfield" > > wrote: > > > > > > > It doesn't work when I spell it correctly either (and I had done > > > > several tests - but of course the results of misspelling it look the > > > > same as it not working - and it's indicative of my day that I pasted > > > > the result of a bad test! :) > > > > > > > > C:\Users\Sean\clojure>lein new five > > > > ... > > > > C:\Users\Sean\clojure>cd five > > > > C:\Users\Sean\clojure\five>lein try hiccup 1.0.2 > > > > Retrieving lein-try/lein-try/0.1.1/lein-try-0.1.1.pom from clojars > > > > Retrieving lein-try/lein-try/0.1.1/lein-try-0.1.1.jar from clojars > > > > Retrieving org/clojure/clojure/1.2.1/clojure-1.2.1.jar from central > > > > nREPL server started on port 51113 > > > > REPL-y 0.2.0 > > > > Clojure 1.5.1 > > > > Docs: (doc function-name-here) > > > > (find-doc "part-of-name-here") > > > > Source: (source function-name-here) > > > > Javadoc: (javadoc java-object-or-class-here) > > > > Exit: Control+D or (exit) or (quit) > > > > user=> (use 'hiccup.core) > > > > FileNotFoundException Could not locate hiccup/core__init.class or > > > > hiccup/core.clj on classpath: clojure.lang.RT.load (RT.java:443) > > > > user=> ^D > > > > Bye for now! > > > > > > > > C:\Users\Sean\clojure\five>cd .. > > > > C:\Users\Sean\clojure>lein try hiccup 1.0.2 > > > > nREPL server started on port 51183 > > > > REPL-y 0.2.0 > > > > Clojure 1.5.1 > > > > Docs: (doc function-name-here) > > > > (find-doc "part-of-name-here") > > > > Source: (source function-name-here) > > > > Javadoc: (javadoc java-object-or-class-here) > > > > Exit: Control+D or (exit) or (quit) > > > > user=> (use 'hiccup.core) > > > > nil > > > > user=> ^D > > > > Bye for now! > > > > C:\Users\Sean\clojure> > > > > > > > > (and that's just to show it failing the same way on Windows 8 (with > > > > GNU on Windows) as it does on Mac!) > > > > > > > > Sean > > > > > > > > On Sat, Jul 13, 2013 at 9:26 PM, Ryan Neufeld > > > > > > wrote: > > > > > It looks like you tried to use hiccup.ocre instead of core > > > > > > > > > > -- > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Clojure" group. > > > > > To post to this group, send email to clojure@googlegroups.com > > > > > Note that posts from new members are moderated - please be patient > > with > > > > your first post. > > > > > To unsubscribe from 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/groups/opt_out. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sean A Corfield -- (904) 302-SEAN > > > > An Architect's View -- http://corfield.org/ > > > > World Singles, LLC. -- http://worldsingles.com/ > > > >
Re: [ANN]: Introducing lein-try
After reading this thread, I think we need another plug in to try the try plugin which in turn may fail which would trigger the need for another try plugin which Isn't this recursive a bit ? : Luc > Can you pop that in an issue on the project. In the mean time I'll see if I > reproduce that problem. > On Jul 13, 2013 11:30 PM, "Sean Corfield" wrote: > > > It doesn't work when I spell it correctly either (and I had done > > several tests - but of course the results of misspelling it look the > > same as it not working - and it's indicative of my day that I pasted > > the result of a bad test! :) > > > > C:\Users\Sean\clojure>lein new five > > ... > > C:\Users\Sean\clojure>cd five > > C:\Users\Sean\clojure\five>lein try hiccup 1.0.2 > > Retrieving lein-try/lein-try/0.1.1/lein-try-0.1.1.pom from clojars > > Retrieving lein-try/lein-try/0.1.1/lein-try-0.1.1.jar from clojars > > Retrieving org/clojure/clojure/1.2.1/clojure-1.2.1.jar from central > > nREPL server started on port 51113 > > REPL-y 0.2.0 > > Clojure 1.5.1 > > Docs: (doc function-name-here) > > (find-doc "part-of-name-here") > > Source: (source function-name-here) > > Javadoc: (javadoc java-object-or-class-here) > > Exit: Control+D or (exit) or (quit) > > user=> (use 'hiccup.core) > > FileNotFoundException Could not locate hiccup/core__init.class or > > hiccup/core.clj on classpath: clojure.lang.RT.load (RT.java:443) > > user=> ^D > > Bye for now! > > > > C:\Users\Sean\clojure\five>cd .. > > C:\Users\Sean\clojure>lein try hiccup 1.0.2 > > nREPL server started on port 51183 > > REPL-y 0.2.0 > > Clojure 1.5.1 > > Docs: (doc function-name-here) > > (find-doc "part-of-name-here") > > Source: (source function-name-here) > > Javadoc: (javadoc java-object-or-class-here) > > Exit: Control+D or (exit) or (quit) > > user=> (use 'hiccup.core) > > nil > > user=> ^D > > Bye for now! > > C:\Users\Sean\clojure> > > > > (and that's just to show it failing the same way on Windows 8 (with > > GNU on Windows) as it does on Mac!) > > > > Sean > > > > On Sat, Jul 13, 2013 at 9:26 PM, Ryan Neufeld > > wrote: > > > It looks like you tried to use hiccup.ocre instead of core > > > > > > -- > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > your first post. > > > To unsubscribe from 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/groups/opt_out. > > > > > > > > > > > > > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View -- http://corfield.org/ > > World Singles, LLC. -- http://worldsingles.com/ > > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > 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/YZDYufCtKRA/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/groups/opt_out. > > > > >
Re: How to implement a distributed and concurrent system in Clojure?
clj-zookeeper + avout. We run our solution on clusters of small nodes, we needed a lightweight solution. We implemented cluster queues and use avout locking. Our configuration is also stored in zookeeper as clojure expressions. We isolated this in a coordinator module so nothing spills out in the rest of the code. We could swap this for another alternative with minimal headaches but so far it scales pretty well. For inter cluster exchanges we are using zeromq but we do not need the same tight intra cluster integration. Luc P. > I'd like to hear others opinions on this too. I don't believe Clojure has > anything built in at this point. My plan of action (not yet implemented) is > to use gearman(possibly java, but it seems that it is no longer updated) > and zeroconf for clusters (just for automatic master determination). > > I know there is support for Hadoop in Clojure as well, which does not fit > my needs but may fit your needs. A quick google search will get you started. > > Immutant has support for clustering too, but I believe it requires > leiningen to start, where I need to compile everything into a single jar. > Immutant under the hood is using JBoss' message queue, so that may be an > option to explore as well. > > I'm curious what others are doing. > > Best., > --Joseph > > On Wednesday, July 3, 2013 4:26:53 AM UTC-5, Hussein B. wrote: > > > > Hi, > > > > I read recently on the internet that Clojure concurrency tools make it > > easy to implement a highly concurrent system but on a single machine. > > > > But how to implement a highly concurrent system that runs on a multiple > > machines? > > > > Erlang, Elixir and Scala have the Actors model. > > > > Please correct me if I'm wrong. > > > > Thanks for help and time. > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Multiple args: opts map vs inline arguments
I agree, this approach fits with our code base. Apply induces a significant hit and should be avoided when performance is critical. I tend to let the computer do its job and free my brain estate for more useful things until performance becomes critical. A kind of laziness :)) Luc P. > My rule of thumb for this is if that's something that will be "static" (as > in, set once in the source and never changes) kw options are fine, if it is > likely to be manipulated, is the result of some previous computation, then > a map fits better. > > apply also has a performance cost that's not always welcome. > > On Tuesday, June 18, 2013 3:38:55 PM UTC+2, Luc wrote: > > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > Sub-selecting options with select-key makes things easier to read when > > pruning > > options used by internal fns. > > > > Marginally slower but less brain estate is required to remember valid > > options. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide > > it. > > > > Luc P. > > > > > > > > -- > > Softaddicts> sent by ibisMail from > > my ipad! > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Multiple args: opts map vs inline arguments
I think it's more a matter of taste at this point and what choices were made earlier. I chose the explicit destructuring route on optional args in the fn definition a while ago. Nothing prevents us from dealing with anonymous option maps when appropriate, merging, sub-selecting keys, ... (:or ) But it does not happen very often in our world. As far as calling libs underneath, we just try to avoid option name clashing and sub select whatever options need to be passed to these libs often by name not as a generic map. We do not attempt to hide low level options in our APIs. Of course if a external lib API changes it has some effect on the calling code but it's been a non issue so far. A macro to hide the apply call in this specific case does not appear to me as a lot of work if it simplifies the calling conventions in some edge cases. It would be different if we had this everywhere. My opinion is obviously biased by the choices we made earlier and the way our code base evolved but so far we did not feel any pain choosing this route. Luc P. > On 18 June 2013 14:38, Softaddicts wrote: > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > You can use destructuring on rolled up option maps as well. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > I find myself constructing option maps quite often, but then I use a few > libraries heavy on options, like clj-http, which benefit from merging > option maps. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > > > > It seems a fair bit of work to avoid a pair of brackets. > > If you need a macro or function to work around an issue created by some > optional syntax sugar, I'd question whether that syntax sugar is worth it. > > - 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Multiple args: opts map vs inline arguments
I was not aware of this, we used a macro I think in a few places, mainly to avoid adding an extra call. Luc P. > The keyword arguments vs. (apply (apply)) issue has come up before: > https://groups.google.com/d/topic/clojure-dev/9ctJC-LXNps/discussion > My take is: Use keyword arguments wherever appropriate and keep apply-kw > handy: http://dev.clojure.org/jira/browse/CINCU-3 > > > 2013/6/18 Softaddicts > > > I use destructuring most of the time, the main benefits I see are runtime > > validation > > of typo errors in the option names, better doc strings and the ability to > > provide defaults > > where nil does not make any sense. > > > > Of course you may need to use apply to pass options in turn to another fn > > but I found out that this happens most of the time internally, not in the > > public API. > > > > Sub-selecting options with select-key makes things easier to read when > > pruning > > options used by internal fns. > > > > Marginally slower but less brain estate is required to remember valid > > options. > > > > If the apply stuff gets repeatedly in the way, then use a macro to hide it. > > > > Luc P. > > > > > > > > -- > > Softaddicts sent by ibisMail from my ipad! > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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/groups/opt_out. > > > > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Multiple args: opts map vs inline arguments
I use destructuring most of the time, the main benefits I see are runtime validation of typo errors in the option names, better doc strings and the ability to provide defaults where nil does not make any sense. Of course you may need to use apply to pass options in turn to another fn but I found out that this happens most of the time internally, not in the public API. Sub-selecting options with select-key makes things easier to read when pruning options used by internal fns. Marginally slower but less brain estate is required to remember valid options. If the apply stuff gets repeatedly in the way, then use a macro to hide it. Luc P. -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
Re: Any suggestions for configuration solution in Clojure or Java world?
We built our own tool using zookeeper. We need to manage clusters of nodes, clearly property files were not scalable enough to be of any help here. All the configuration values are written using Clojure expressions, not just EDN like stuff, we do eval code loaded in the configuration to provide extensibility. We wrote a DSL to maintain the configuration. You can then implement versioning, rollbacks, whatever features you may need. When a node boots, it needs a 4 lines property file to find its root in the cluster configuration. Any process on the node pulls it's configuration from this root. This approach might be too heavy for your needs however. Luc P. > After suffer xml or properties configuration for long time, I'm looking for > a new configuration solution for Clojure or Java. I hope below features, > priority from high to low: > > 1. readable format and easy to write. XML is the opposite example, which is > not easy to edit and not readable. I like Json or YAML, especially JSON. > 2. support difference environments. The difficult things I have are > distributes difference package for difference environments (dev, gamma or > online). My practice are write difference set of configuration files for > each environment, for example we have database-dev.properties and > database-online.properties for respectively dev and online environment, > then pass a argument to startup script to control which file to load. it's > just work, but the problem are there are only small part of config is > difference between and dev and online, but I have to rewrite and maintain > all config in two files. > 3. easy to organize if there are a lot of configuration files. It's very > common that there are many configurations distributes in difference files. > Sometimes one file's configuration need override another. we need a > solution to management them. > 4. we can very easy override configuration by CLI argument or system > environment variable. Sometimes we have to temporarily change configuration > for debug or troubleshooting purpose. I hope we can easy to override > configuration not change the configuration files. > > For the #1, the HOCON ( https://github.com/typesafehub/config ) is the best > config syntax what I have ever seen. But I didn't find out a solution which > can satisfy rest of other features. Do you have any suggestions? 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/groups/opt_out. > > > -- Softaddicts sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/groups/opt_out.
