Re: How to go about 'proving' why dynamically typed languages are better.
I suspect you are going to have zero success "proving" the superiority of dynamic languages (in an academic proof sense). For a start, people are even going to disagree about the precise definition of "better". What matters more: Runtime performance? Flexibility with respect to changing requirements? Ease of learning? Minimisation of typing? Ease of language implementation? Etc. Any such "proof" based on your own definition of "better" isn't likely to convince others who hold different views. My suggestion: just don't worry about it, be pragmatic and use whatever you find helps you to build useful software. Ultimately, that is the main measure of success for a practical general purpose programming language. In particular, I suggest ignoring anyone who launches a "barrage of abuse". Language trolls probably aren't going to give you a sensible conversation in any case. On Sunday, 6 October 2013 11:35:20 UTC+8, zcaudate wrote: > > I'm a little bit miffed over this current craze of `types` and > `correctness` of programs. It smells to me of the whole `object` craze of > the last two decades. I agree that types (like objects) have their uses, > especially in very well defined problems, but they have got me in trouble > over and over again when I am working in an area where the goal is unclear > and requirements are constantly changing. > > BTW... This is no means a criticism of all the type system work that is > going on in the clojure community. I am a huge fan of Ambrose's Typed > Clojure project because it gives me the *option *of using types... not > shoving it down my throat. I like the freedom to choose. > > My experience of programming in clojure has freed me from thinking about > types and hierarchies and this article rings so true: > http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. > > However, everywhere I look, there are smug type-weenies telling me that my > dynamically typed program is bad because it cannot be `proven correct` and > not `checked by the compiler`. This question on SO really makes me > angry > http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages > > because no one is defending dynamic languages on there. The reason is very > simple. because we don`t have a theory to back us up! > > I do want to put up an counter argument against this barrage of abuse > against dynamic languages. And I want to put some academic 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.
Re: How to go about 'proving' why dynamically typed languages are better.
Thanks Mike for your reminder to be pragmatic. It is definitely the way to go.
Clojure's an incredible language for this.
This is going to be a longish post as I should better explain my position. It
is just a brief sketch of the problem but I think that we should be thinking
about it more as a fun exercise rather than a way to troll the haskell/scala/ml
mailing lists.
I'm not the type of person to get overly academic but I still want to have
`faith` in the tools that I'm using. In Indian traditions of philosophy, the
term `shraddah` is translated as `faith` but it literally means `that which
binds you` or `that which is unwavering`. Logical foundations of practices and
beliefs are debated by practitioners and scholars alike. To debate and win
against those in opposition, one has to have a good reason to believe in their
practice. In other words, academics is a VERY powerful tool for faith.
Because of the vast amounts of academic work around types, we now have a `type`
priesthood and an increasingly mass of `type converts` who are very
inflammatory against anything non-typed languages. The cult of haskell will
always look down on the cult of lisp/javascript/python/ruby, laugh and say `you
guys suck because you don`t have A, B, C which are features of type inference`.
Now with the `cult of clojure`, we can say YES WE DO (Typed Clojure)… but not
only that, we should also be able to say:
"Because we have optional typing, here are a bunch of problems that we can
solve very easy because X, Y and Z are not restricted by type inference."
Now The the debate actually moves forward, so that we ask ourselves whether
type-inference is suitable for solving a particular class of problems rather
than putting ourselves into opposite camps.
I have to come back to Godel's work as it is (quoting the lecturer) `The most
profound result to have come out of logic for the last 2000 years, ever since
the time of Aristotle`. What Godel did, was to write a hack that crashed a what
was thought to be an uncrashable system.
Principia Mathematica (PM) was a huge book which described how one can of about
using a subset of mathematics to reason without running into Russell`s Paradox
(which is the mathematical equivalent of saying `this statement is false`). It
was found that ANY system that referred back to oneself had the potential to
have this problem and so all of this circular referencing had to be eliminated.
The reason why the book was so thick was because most of the book was devoted
to teaching people how to write mathematics without using circular reference.
It was dense.
Godel constructed an equivalent system of calculation to that of PM and showed
that anytime the `+` operator was in the system, then it was possible to get
the system to talk about itself. Therefore, the phrase `This statement is
unprovable using our system` will result in a paradox in a system that was
thought the be free of them. Thus, Godel used the logic presented in the
framework itself to cause its own downfall.
This result put mathematics in its place, not as the single source of truth as
Russell and Whitehead, the authors of PM had wanted, but as an incredibly tool
despite its inconsistencies. It also eliminated the need for future
mathematicians to waste their time in order to build a complete system of
mathematics - Godel had proved beyond a shadow of a doubt that this was an
impossible task.
I see history repeating itself with the offspring of PM (type theory). Like PM,
It is brilliant and to be honest, it is too abstract for me. However, it is my
understanding that a lot of the leading research is repeating that of PM but
with an emphasis on computation. To avoid Russell`s paradox, types are always
hierarchical, never circular. To express circular referencing of types in a
none circular way requires a lot of time of a lot of smart people.
There is therefore a lot of pomp and ceremony in order to create a `correct`
and `complete` system of programming I don't think any of the researchers claim
this but it is sure marketed that way.
I believe that we have to put type theory in its proper place as a tool for
programmers and not as the saviour for programming (that mantle belongs to lisp
of course =p ) For example:
- one area that is difficult using types is to define multiple hierarchies
over objects - like properies of can-fly, can-swim, can-run over birds, mammals
and reptiles.
- Another area is with partial data. That is, when does a rose not become a
rose? when it looses its colour? fragrance? shape?. For example… can {:colour
:red} be considered a rose, even though a rose may be red?
On 06/10/2013, at 6:02 PM, Mikera wrote:
> I suspect you are going to have zero success "proving" the superiority of
> dynamic languages (in an academic proof sense). For a start, people are even
> going to disagree about the precise definition of "better". What matters
> more: Runtime pe
Who uses HtmlUnit?
Hi all, did anyone give a try to this java based HTMLUnit headless browser for cljs unit test to be used of phantomjs? http://htmlunit.sourceforge.net/ Thanks Mimmo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: Who uses HtmlUnit?
I've never tried it for unit testing, but it's the de facto Java library for headless browsers and it's the driving force behind products such as Selenium WebDriver => http://seleniumhq.org/ I mostly use it for bot creation/automation and it supports many versions of popular web browsers such as Firefox (3.6, 10, 17), Chrome (+ 16), and IE (6, 7, 8, 9) => http://htmlunit.sourceforge.net/apidocs/com/gargoylesoftware/htmlunit/BrowserVersion.html 06.10.2013, 20:23, "Mimmo Cosenza" :Hi all,did anyone give a try to this java based HTMLUnit headless browser for cljs unit test to be used of phantomjs?http://htmlunit.sourceforge.net/ThanksMimmo-- -- You received this message because you are subscribed to the GoogleGroups "Clojure" group.To post to this group, send email to clojure@googlegroups.comNote that posts from new members are moderated - please be patient with your first post.To unsubscribe from this group, send email toclojure+unsubscr...@googlegroups.comFor more options, visit this group athttp://groups.google.com/group/clojure?hl=en--- You received this message because you are subscribed to the Google Groups "Clojure" group.To unsubscribe from 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.
Re: Who uses HtmlUnit?
WebDriver's HtmlUnitDriver is only one of many supported drivers. Most Selenium-using teams I've been on have driven real browsers using another driver (which among other benefits allows one to generate realistic screen shots). The one team I was on that used HtmlUnit (a couple years ago) blamed it for sporadic test failures and had their own patched version that supposedly fixed concurrency issues (that they'd submitted as a patch but had not been accepted). I wasn't close to that research, so I can't attest to the issues personally. On Sun, Oct 6, 2013 at 8:40 AM, Kelker Ryan wrote: > I've never tried it for unit testing, but it's the de facto Java library > for headless browsers and it's the driving force behind products such as > Selenium WebDriver => http://seleniumhq.org/ > > I mostly use it for bot creation/automation and it supports many versions > of popular web browsers such as Firefox (3.6, 10, 17), Chrome (+ 16), and > IE (6, 7, 8, 9) => > http://htmlunit.sourceforge.net/apidocs/com/gargoylesoftware/htmlunit/BrowserVersion.html > > 06.10.2013, 20:23, "Mimmo Cosenza" : > > Hi all, > did anyone give a try to this java based HTMLUnit headless browser for > cljs unit test to be used of phantomjs? > > http://htmlunit.sourceforge.net/ > > Thanks > > Mimmo > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from 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. > -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
I support the sentiment expressed in your email. +1 Type systems are nice, just don't force them upon anyone. Keep the C++ at bay. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 6, 2013, at 7:16 AM, Chris Zheng wrote: > Thanks Mike for your reminder to be pragmatic. It is definitely the way to > go. Clojure's an incredible language for this. > > This is going to be a longish post as I should better explain my position. It > is just a brief sketch of the problem but I think that we should be thinking > about it more as a fun exercise rather than a way to troll the > haskell/scala/ml mailing lists. > > I'm not the type of person to get overly academic but I still want to have > `faith` in the tools that I'm using. In Indian traditions of philosophy, the > term `shraddah` is translated as `faith` but it literally means `that which > binds you` or `that which is unwavering`. Logical foundations of practices > and beliefs are debated by practitioners and scholars alike. To debate and > win against those in opposition, one has to have a good reason to believe in > their practice. In other words, academics is a VERY powerful tool for faith. > > Because of the vast amounts of academic work around types, we now have a > `type` priesthood and an increasingly mass of `type converts` who are very > inflammatory against anything non-typed languages. The cult of haskell will > always look down on the cult of lisp/javascript/python/ruby, laugh and say > `you guys suck because you don`t have A, B, C which are features of type > inference`. > > Now with the `cult of clojure`, we can say YES WE DO (Typed Clojure)… but not > only that, we should also be able to say: > > "Because we have optional typing, here are a bunch of problems that we can > solve very easy because X, Y and Z are not restricted by type inference." > > Now The the debate actually moves forward, so that we ask ourselves whether > type-inference is suitable for solving a particular class of problems rather > than putting ourselves into opposite camps. > > I have to come back to Godel's work as it is (quoting the lecturer) `The most > profound result to have come out of logic for the last 2000 years, ever since > the time of Aristotle`. What Godel did, was to write a hack that crashed a > what was thought to be an uncrashable system. > > Principia Mathematica (PM) was a huge book which described how one can of > about using a subset of mathematics to reason without running into Russell`s > Paradox (which is the mathematical equivalent of saying `this statement is > false`). It was found that ANY system that referred back to oneself had the > potential to have this problem and so all of this circular referencing had to > be eliminated. The reason why the book was so thick was because most of the > book was devoted to teaching people how to write mathematics without using > circular reference. It was dense. > > Godel constructed an equivalent system of calculation to that of PM and > showed that anytime the `+` operator was in the system, then it was possible > to get the system to talk about itself. Therefore, the phrase `This statement > is unprovable using our system` will result in a paradox in a system that was > thought the be free of them. Thus, Godel used the logic presented in the > framework itself to cause its own downfall. > > This result put mathematics in its place, not as the single source of truth > as Russell and Whitehead, the authors of PM had wanted, but as an incredibly > tool despite its inconsistencies. It also eliminated the need for future > mathematicians to waste their time in order to build a complete system of > mathematics - Godel had proved beyond a shadow of a doubt that this was an > impossible task. > > I see history repeating itself with the offspring of PM (type theory). Like > PM, It is brilliant and to be honest, it is too abstract for me. However, it > is my understanding that a lot of the leading research is repeating that of > PM but with an emphasis on computation. To avoid Russell`s paradox, types are > always hierarchical, never circular. To express circular referencing of types > in a none circular way requires a lot of time of a lot of smart people. > > There is therefore a lot of pomp and ceremony in order to create a `correct` > and `complete` system of programming I don't think any of the researchers > claim this but it is sure marketed that way. > > I believe that we have to put type theory in its proper place as a tool for > programmers and not as the saviour for programming (that mantle belongs to > lisp of course =p ) For example: > - one area that is difficult using types is to define multiple hierarchies > over objects - like properies of can-fly, can-swim, can-run over birds, > mammals and reptiles. > - Another area is with partial data. That is, when does a rose not become a > ros
Re: Who uses HtmlUnit?
I've used HTMLunit, but the Javascript implementation used is rather slow compared to regular JS in browsers. Since the webframework I need to test is rather JS heavy, this is a pretty big problem. I had hopes that they would switch from Rhino to Nashorn, but there currently aren't plans for that. Also, it has it's own idiosynchrasies browserwise, and I couldn't convince our developers to work around those by supporting yet another browser, just for testing. It would be marvellous to have a headless browser that uses less resources than a regular, but for my uses HTMLunit just didn't cut it. I should take a look at the PhantomJS browser and Ghostscript (and it's Webdriver support) one of these days. On Sunday, October 6, 2013 1:23:22 PM UTC+2, Magomimmo wrote: > > Hi all, > did anyone give a try to this java based HTMLUnit headless browser for > cljs unit test to be used of phantomjs? > > http://htmlunit.sourceforge.net/ > > Thanks > > Mimmo > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: Trying to use Heroku and Postgresql
Yes, it turned out that 'export' is for unix, I had to use 'set' and it worked. This was suggested by juan.facorro at SO: http://stackoverflow.com/questions/19204548/how-do-you-connect-to-local-postgresql-in-heroku#comment28425326_19204548 On Saturday, October 5, 2013 5:13:53 PM UTC-4, Bruce Adams wrote: > > (System/getenv "DATABASE_URL") is returning *nil*. This will happen when > the system environment variable DATABASE_URL is not defined. > > - Bruce > > On Sat, Oct 5, 2013, at 04:54 PM, Zeynel wrote: > > I am going through this Heroku tutorial > https://devcenter.heroku.com/articles/clojure-web-application. I am > getting the following error when I try to create a table in the local > Postgresql database > > user=>(sql/with-connection (System/getenv "DATABASE_URL") > (sql/create-table :testing [:data :text])) > > > IllegalArgumentException db-spec null is missing a required parameter > > clojure.java.jdbc/get-connection (jdbc.clj:192) > > What am I doing wrong? > > I also have a question at SO for a related issue: > http://stackoverflow.com/questions/19201133/postgresql-log-autovacuum-launcher-started-is-hung-apparently > > > -- > -- > 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. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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.
Newbie seeks advice
Hello, I'm new to closure and functional programming and need some adviec/help with my oldschool programming style. I've written the following little program and hope someone could help me to improve it. The programm computes numbers through an iterative function , put the numbers in a 'shift buffer' and computes some value from the entries in that buffer. I'm sure it's not optimal at all and could be improved a lot. I've used a vector (and not a list) as buffer because I have to address and use the elements using nth. Hope thats ok, but not sure of that. I wish I could enter the new values at the start (left side) but found noe efficient way to do it. With vector one should use conj to add new values and that could only be done from the right side of the buffer , right? I'm sure there is a much better way to build such a 'shift buffer', any ideas? Another concern I have is the used of def's in the iteration loop. Overwriting the x and the buffer may not be optimal, but I have no idea of another (more functional) approch to that. ; defines my function (defn myfunc [x] (mod (+ (inc x) (rand-int 10) ) 10)) ; creates buffer and sets initial values (def buffer (vec (take 5 (repeat 0))) ) ; creating a 'shift buffer': removes oldest entry and adds a new value at the end (defn in_buffer [buff x] (conj (subvec buff 1) x)) ; sets start value (def x 0) ; iteration loop (dorun(for [i (range 20)] (do (def x (myfunc x)) ; computes new value using myfunc and sets new x value (def buffer (in_buffer buffer x)); writes value into buffer and sets new buffer (println buffer) ;print buffer (println (+ (nth buffer 1) (nth buffer 3)) ; ;compute with values from bufffer Thank you or your help. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Newbie seeks advice
The key to writing an algorithm functionally is to break it up into simple components. You're performing three calculations: (def x (myfunc x)) (def buffer (in_buffer buffer x)) (+ (nth buffer 1) (nth buffer 3)) Let's tackle each in turn. The first is a continually changing value of x, with the new value calculated from the previous. We can represent this as a sequence, e.g. (x, (f x), (f (f x)), (f (f (f x))), ...) We could write a function to do this for us: (defn iterate [f x] (cons x (lazy-seq (iterate f (f x) But fortunately the iterate function already exists in the clojure.core namespace. So this solves your first calculation: (def x (myfunc x)) ==> (iterate myfunc 0) Next, we want a sliding buffer of 5 values. Again, we could represent this as a sequence, e.g. ([a b c d e], [b c d e f], [c d e f g], ...) We could write our own function for this (defn sliding-buffer [n xs] (cons (take n xs) (lazy-seq (sliding-buffer n (rest xs) But it turns out there's already a function to do this in clojure.core, called partition: (def buffer (in_buffer buffer x)) ==> (partition 5 1 (iterate myfunc 0)) Okay, we're nearly there. Now we just need to add the second and fourth numbers (indexes 1 and 3) together for each value in the sequence. We can do this with a map: (map (fn [b] (+ (nth b 1) (nth b 2))) (partition 5 1 (iterate myfunc 0))) Or, with a bit of syntax sugar: (->> (iterate myfunc 0) (partition 5 1) (map #(+ (nth % 1) (nth % 3 In my opinion, one of the key difficulties with programming in a functional style is to realise that a single loop in an imperative program may hide multiple pieces of functionality. The functional style favours splitting this out into sequence operations that do one thing each. - James On 6 October 2013 20:02, vMac wrote: > Hello, > > I'm new to closure and functional programming and need some adviec/help > with > my oldschool programming style. > I've written the following little program and hope someone could help me > to improve it. > > The programm computes numbers through an iterative function , put the > numbers in a 'shift buffer' and computes some value from the entries > in that buffer. > > I'm sure it's not optimal at all and could be improved a lot. > I've used a vector (and not a list) as buffer because I have to address > and use the elements using nth. Hope thats ok, but not sure of that. > I wish I could enter the new values at the start (left side) but found noe > efficient way to do it. With vector one should use conj to add new values > and > that could only be done from the right side of the buffer , right? > I'm sure there is a much better way to build such a 'shift buffer', any > ideas? > > Another concern I have is the used of def's in the iteration loop. > Overwriting the x and the buffer may not be optimal, but I have no idea of > another (more functional) approch to that. > > > ; defines my function > (defn myfunc [x] > (mod (+ (inc x) (rand-int 10) ) 10)) > > ; creates buffer and sets initial values > (def buffer (vec (take 5 (repeat 0))) ) > > ; creating a 'shift buffer': removes oldest entry and adds a new value at > the end > > (defn in_buffer [buff x] > (conj (subvec buff 1) x)) > > ; sets start value > (def x 0) > > ; iteration loop > (dorun(for [i (range 20)] > > (do > (def x (myfunc x)) ; computes new value using myfunc and sets > new x value > (def buffer (in_buffer buffer x)); writes value into buffer and > sets new buffer > (println buffer) ;print buffer > (println (+ (nth buffer 1) (nth buffer 3)) ; ;compute with > values from bufffer > > > > > Thank you or your help. > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/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 t
Re: how to reload Clojure files while connected to Clojurescript browser repl in Emacs?
On Wed, Oct 2, 2013 at 3:17 AM, George Oliver wrote: > On Sunday, September 29, 2013 8:12:23 PM UTC-7, Tim Visher wrote: > >> Now with nrepl's ability to have multiple sessions open at once (an >> ability I haven't taken any advantage of personally), you should be >> able to have a JVM nrepl open _and_ a browser repl nrepl session, both >> of which would be modifying client and server sides of the code >> respectively. > > The > functionality in Austin enables browser refreshes while maintaining a > connected browser repl, dealing with state is another issue. That sounds really cool. I was not aware that Austin could do this. Do you have any pointers to documentation about it? Again, my model of how the system works is that the browser _is_ the repl, so refreshing the browser completely resets you back to the last time the clojurescript was built. -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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.
boolean java interopt puzzle/bug?!
Hey Devs, I have fighting against an issue that can summarized in the following line: user=> (not (new java.lang.Boolean false)) false Is that behavior correct? Because if I run: user=> (type false) java.lang.Boolean Can someone help me to understand it? Thanks, -- Bauna -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: boolean java interopt puzzle/bug?!
Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 On Sun, Oct 6, 2013 at 5:27 PM, Pablo Nussembaum wrote: > Hey Devs, > I have fighting against an issue that can summarized in the following line: > > user=> (not (new java.lang.Boolean false)) > false > > Is that behavior correct? > > Because if I run: > user=> (type false) > java.lang.Boolean > > Can someone help me to understand it? > > Thanks, > -- > Bauna > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from 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.
How to go about 'proving' why dynamically typed languages are better
> zcaudate Oct 05 08:35PM -0700 I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell This interview covers some of the strong-types vs flexible development (apparent) dichotomy, but in a playful, open and non-dogmatic way. (catmatic?) Simon Peyton Jones is one of the Haskell leaders, yet admits to being envious of type-free generics. Joe Armstrong of Erlang fame also sees the benefit to thinking in and annotating types. These two are both leaders of typed or dynamic cults but have a pleasant friendly and frank conversation about the issues. (Erlang's Dialyzer sounds somewhat like core.typed) A sample: SPJ: So, I've told you what I most envy about Erlang. What do you most envy about Haskell? JA: All the types. I mean they're very nice. I wish we had them. On the other hand, wouldn't you love to have all these generic turn-to-binary, these sort of things? How can you live without them? SPJ: I have a little bit of residual envy about generics. JA: You just take anything and compare it to the serializer and then send it? SPJ: That's sinfully easy, and shouldn't be allowed. So if these two can agree that there's strengths and weaknesses in both approaches, that settles it for me. It's a matter of knowing your trade-offs and choosing your tools appropriately. My suspicion is that type affinity is related to some trait of personality, and so trying to "prove" superiority is a likely to work as "proving" you are right in any other clash of personalities. Brad -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: New core.matrix 0.11.0 release
Hi all, New version of core.matrix now available on Clojars: https://clojars.org/net.mikera/core.matrix/versions/0.11.0 Key items of note: - Dmitry's GSoC NDArray project is now the default core.matrix implementation - this is a big milestone, congrats Dmitry! - Everything is now AOT-compiled. This increases the size of the .jar file, but should improve performance, especially around startup time - Lots of performance enhancements (e.g. matrix inverses calculated using LU-decomposition algorithm) - A few minor bug fixes - Repository on github has been renamed (old links should still work): https://github.com/mikera/core.matrix As always, feedback / suggestions much appreciated. Mike. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: boolean java interopt puzzle/bug?!
Gary Trakhman writes: > Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed > reasons (I think) anything that checks for truthiness uses java's ==, which > will fail on any new Boolean object. Usually, this isn't a problem, but > sometimes it is. You can see that this assumption is pervasive by looking > at the implementations of 'true?' and 'false?', which use identical? and > the check for != Boolean.FALSE in > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 ...and further, my understanding is that the Boolean constructors are more or less considered a mistake, and you should effectively never use them. For example: http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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: boolean java interopt puzzle/bug?!
There is also this page on ClojureDocs that might shed some light on this quirk: http://clojuredocs.org/clojure_core/clojure.core/if On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning wrote: > Gary Trakhman writes: > > > Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for > speed > > reasons (I think) anything that checks for truthiness uses java's ==, > which > > will fail on any new Boolean object. Usually, this isn't a problem, but > > sometimes it is. You can see that this assumption is pervasive by > looking > > at the implementations of 'true?' and 'false?', which use identical? and > > the check for != Boolean.FALSE in > > > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 > > ...and further, my understanding is that the Boolean constructors are > more or less considered a mistake, and you should effectively never > use them. For example: > > http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ > > Hope this helps > -- > Rob Browning > rlb @defaultvalue.org and @debian.org > GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A > GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from 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.
Re: clj-ldap - Clojure LDAP client
Hi - is anyone maintaining any of these ldap libraries?
I ask because:
- neither has updates in 2 years
- the underlying umboundid library now supplies a
"bindAndRevertAuthentication" function that implements what was discussed
previously in this thread - you can bind without mutating the existing
connections (who'd have thought you'd need that? :)
- Paul's fork doesn't let you raise issues, and there are two unapplied
pull requests, which makes me hesitant to do a patch myself.
There's also https://github.com/realestate-com-au/clj-ldap-auth by Mike
Rowe, which seems a bit beta for our needs, but if the others are abandoned
we might start working with that one.
Or is there another library out there I missed? Surely there are lots of
clojure folk doing ldap authentication!
- Korny
On 20 March 2011 23:55, Paul Dorman wrote:
> Thanks for the latest changes, Saul. Your implementation is a little
> different from mine:
>
> (defn bind-connection
> "Change the identity of an existing connection."
> [connection bind-dn password]
> (let [bind-result (.bind connection (bind-request {:bind-dn bind-
> dn :password password}))]
> (if (= ResultCode/SUCCESS (.getResultCode bind-result))
> connection
> (throw (LDAPException. bind-result)
>
> This enables the application code to handle the exception
> appropriately (was the return value false because of invalid
> credentials, or because of some other reason?). It also (I hope)
> provides the capability to take a connection from the pool, change its
> identity and perform some subsequent action(s) such as changing
> attribute values.
>
> I haven't yet confirmed if what I have above will work in the way I
> describe, but I'm pretty confident that you'll want a connection
> returned by bind/bind-connection function. A naive authentication
> scheme could be implemented by the application like so:
>
> (defn can-bind?
> [attribute value password]
> (def search-result (ldap/search conn base-dn {:filter (<<
> "(~{attribute}=~{value})") :attributes [:dn]}))
> (try
> (ldap/bind-connection conn (:dn (first search-result)) password)
> true
> (catch Exception _ false)))
>
> i.e. (can-bind? "uid" "joe" "supersecretpassword")
>
> I'm a complete beginner at Clojure (and LDAP for that matter), and
> there's a number of things that I'm wondering about, such as binding
> to a server-set, where failure to bind due to the unavailability of
> one or more members causes a bind request to be sent to the next. The
> thing I'm struggling with at the moment is how to manage connection
> state as its identity is changed for each new bind. In particular, I
> want to use getConnection() to retrieve the bind connection from the
> pool so it can be reused (which isn't currently happening), before
> calling the releaseConnection() method.
>
> Sorry for not getting the above to you earlier - I've been spending a
> lot of time in the REPL trying to get this right. 1:50 on Monday
> morning now though, so I think I'll have to reluctantly step away from
> the computer.
>
> Regards,
> Paul
>
> On Mar 20, 11:34 pm, Saul Hazledine wrote:
> > On Mar 16, 9:30 am, Ray Miller wrote:
> >
> > > On 15 March 2011 08:46, Saul Hazledine wrote:
> >
> > > > On Mar 15, 1:30 am, Paul Dorman wrote:
> > > > One thought though is that it may be quicker simply do a lookup on
> the
> > > > directory server, obtain the password and then do a compare. In
> > > > OpenLDAP, posixUser uids are indexed by default. Java libraries are
> > > > available for most password encryption algorithms. This is the
> > > > approach I use - do you know of any problems with my method?
> >
> > > Certainly when I was running LDAP servers we did not allow passwords
> > > to be retrieved from the server, as they are then susceptible to an
> > > offline dictionary attack. To authenticate users, you had to send a
> > > bind request to the server.
> >
> > This is a very good point which I have added to the documentation.
> >
> > I have made the bind functionality public and released version 0.0.4
> > of clj-ldap.
> >
> > Saul
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
Kornelis Sietsma korny at my surname dot com http://korny.info
.fnord { display: none !important; }
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more opt
How to suppress warnings?
Hello I'm using core.async, but always see the following warnings. How do I suppress them? WARNING: map already refers to: #'clojure.core/map in namespace: message-bus.latam, being replaced by: #'clojure.core.async/map WARNING: into already refers to: #'clojure.core/into in namespace: message-bus.latam, being replaced by: #'clojure.core.async/into WARNING: reduce already refers to: #'clojure.core/reduce in namespace: message-bus.latam, being replaced by: #'clojure.core.async/reduce WARNING: merge already refers to: #'clojure.core/merge in namespace: message-bus.latam, being replaced by: #'clojure.core.async/merge Thanks Gary -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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 suppress warnings?
One way to avoid these warnings being generated in the first place is not to "use" core.async, but "require ... as" it, e.g.: (ns message-bus.latam (:require [core.async :as a])) The down side is that then you must prefix all uses of symbols in core.async with the alias "a/". You can also :exclude the symbols that give the warnings. Then you do not need a prefix for most symbols in core.async, except for the ones that you excluded, which will need a prefix. There is a ticket requesting a change in the current Clojure behavior, but it has not been commented upon by anyone, so there is no evidence whether it will ever become part of Clojure: http://dev.clojure.org/jira/browse/CLJ-1257 Andy On Sun, Oct 6, 2013 at 7:15 PM, Gary Zhao wrote: > Hello > > I'm using core.async, but always see the following warnings. How do I > suppress them? > > WARNING: map already refers to: #'clojure.core/map in namespace: > message-bus.latam, being replaced by: #'clojure.core.async/map > WARNING: into already refers to: #'clojure.core/into in namespace: > message-bus.latam, being replaced by: #'clojure.core.async/into > WARNING: reduce already refers to: #'clojure.core/reduce in namespace: > message-bus.latam, being replaced by: #'clojure.core.async/reduce > WARNING: merge already refers to: #'clojure.core/merge in namespace: > message-bus.latam, being replaced by: #'clojure.core.async/merge > > Thanks > Gary > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from 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.
Re: how to reload Clojure files while connected to Clojurescript browser repl in Emacs?
On Sunday, October 6, 2013 1:26:21 PM UTC-7, Tim Visher wrote: > > > That sounds really cool. I was not aware that Austin could do this. Do > you have any pointers to documentation about it? Again, my model of > how the system works is that the browser _is_ the repl, so refreshing > the browser completely resets you back to the last time the > clojurescript was built. > > The Austin sample project is a good example, https://github.com/cemerick/austin/blob/master/browser-connected-repl-sample/README.md . I could be wrong but my understanding is that the browser is just connecting to your cljs repl which actually is in the 'clojure repl'. Certainly if you refresh the page state built up in the browser is reset, but state in the cljs repl is a different story. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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 reload Clojure files while connected to Clojurescript browser repl in Emacs?
On Sunday, October 6, 2013 11:15:26 PM UTC-7, George Oliver wrote: > > > I could be wrong but my understanding is that the browser is just > connecting to your cljs repl which actually is in the 'clojure repl'. > Certainly if you refresh the page state built up in the browser is reset, > but state in the cljs repl is a different story. > Well, that'll teach me to make a claim without verifying it first -- state in the repl -is- refreshed on a page refresh. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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.
