Here are some functional programming job opportunities that were posted
recently:
Chief Data Scientist at Lazada
http://functionaljobs.com/jobs/8671-chief-data-scientist-at-lazada
Cheers,
Sean Murphy
FunctionalJobs.com
--
--
You received this message because you are subscribed to the
Langohr [1] is a feature complete Clojure client for RabbitMQ.
2.0.1 is a bug fix release. Release notes:
http://blog.clojurewerkz.org/blog/2013/12/22/langohr-2-dot-0-1-is-released/
1. http://clojurerabbitmq.info
--
MK
http://github.com/michaelklishin
http://twitter.com/michaelklishin
--
--
I've spent a night scratching my head about the behavior of proxy-super in
the presence of exceptions as well. I figured it was something like what
you found, but by that point I just didn't trust proxy that much anymore
and wrote that little bit in Java [1]. If I were a better person I would
have
So, I poked around in the code a little, Dave is indeed right - it appears
to be impossible to remove reflection warnings for proxy-super calling
protected methods.
(defn proxy-call-with-super [call this meth]
(let [m (proxy-mappings this)]
(update-proxy this (assoc m meth nil))
(let [ret
It sounds like the vast majority of these apps will simply sit on the
shelf, with no need to ever run them again. So, as long as you have
a way to run them at need, in an accurate and acceptably prompt manner,
you don't have to worry about porting the code.
So, if you can keep a Clojure 1.2 envir
One difficulty with this approach (which I largely following on a similar
operation a while back) is that the modular counterparts have continued
forward and in many cases are not API-compatible with the 1.2 version
anymore (tools.cli is one example that I remember from this transition as
its A
But surely proxy-super should be designed to call protected methods? I'd
have to check but I suspect I call other protected methods using it.
On 23 December 2013 14:13, Dave Ray wrote:
> Seesaw has the same problem with paintComponent. IIRC, it's because it's
> protected. I never found a workar
All talks were recorded. All editing is complete. The bottleneck right now
is in just getting them uploaded which should clear up soon after the
holidays.
Alex
On Sunday, December 22, 2013 3:25:07 PM UTC-6, Richard Cole wrote:
>
> Were any videos of the presentations made? Have they been uploa
The things is that dynamically typed languages are easier to implement than
statically typed languages. Static typing comes down to making statements
about the program and deriving other statements from them. It leads to all
sorts of interesting work including I think into systems like Z. Howeve
Seesaw has the same problem with paintComponent. IIRC, it's because it's
protected. I never found a workaround.
Dave
On Sunday, December 22, 2013, Colin Fleming wrote:
> I actually just wrote a long reply detailing how to type hint 'this', and
> then noticed that you've already done that! This e
Yep, those links were useful. Cheers, Sean.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To
On Sun, Dec 22, 2013 at 4:07 PM, wrote:
> A third option I'm considering is to simply keep running 1.2 and replace the
> contrib libraries with their modular counterparts, moving to 1.5 only after
> that's done. The two difficulties I see here are:
> 1) Ensuring all new reports written during thi
On Sun, Dec 22, 2013 at 4:13 PM, wrote:
> Could you point to more information regarding the numeric changes? I can't
> seem to pinpoint anything in particular here:
> https://github.com/clojure/clojure/blob/1.3.x/changes.txt
That document links to these:
* http://dev.clojure.org/display/design/
Could you point to more information regarding the numeric changes? I can't
seem to pinpoint anything in particular here:
https://github.com/clojure/clojure/blob/1.3.x/changes.txt
On Sunday, December 22, 2013 7:05:13 PM UTC-5, Sean Corfield wrote:
>
> If you truly have "thousands" of Clojure 1.2 a
Thanks, Sean. Yes, the reports are static and not maintained. The lifecycle
of the typical report is as follows:
1) Business requests data
2) Someone writes a report using Clojure
3) Business views the report and may request changes now and then
4) Business eventually loses interest
Part of my pl
A third option I'm considering is to simply keep running 1.2 and replace
the contrib libraries with their modular counterparts, moving to 1.5 only
after that's done. The two difficulties I see here are:
1) Ensuring all new reports written during this process use the modular
libraries
2) What to
If you truly have "thousands" of Clojure 1.2 apps, I'd go with option
1), and look at migrating legacy reports over if you need to do any
maintenance on them. Since Clojure is "just" a Java library, it's
fairly easy to keep the Clojure version locked in each individual
project so there's no reason
At my company, we use Clojure for reporting. Specifically, reports are
written in Clojure which integrate data from a variety of sources and
display the final output to the user in a WPF-based webapp.
For all intents and purposes, each 'report' is a standalone Clojure app,
and most of them use
According to a note I found on Reddit via Google, Conj videos have
historically appeared on the ClojureTV YouTube channel "4-6 weeks
after the event" so I would expect them to start appearing "soon"
through the New Year...
Sean
On Sun, Dec 22, 2013 at 1:25 PM, Richard Cole wrote:
> Were any vide
On Sun, Dec 22, 2013 at 2:55 PM, Sean Corfield wrote:
> For clj-time I'm happy to just see an issue opened on Github (when
> it's back from its current 503 woes!) and happier to see a Pull
> Request.
https://github.com/clj-time/clj-time/issues/100
--
Sean A Corfield -- (904) 302-SEAN
An Architec
For clj-time I'm happy to just see an issue opened on Github (when
it's back from its current 503 woes!) and happier to see a Pull
Request.
For clojure.tools.reader, you'll need to open issues in JIRA as Andy
indicated. Most of the rest sound like Github-based projects so
opening issues, preferabl
Most often, you don't add type hints to code you :use or :require. You
disable the warnings, or accept that you will see a slew of them, or if you
only want to see them in your own code but not in libraries you use, remove
:warn-on-reflection true from your project.clj, and edit your source files
I know this has been discussed before but I could not find anything like a
canonical answer via Google. I just set to
:warn-on-reflection true
in my project.clj and now I get the following warnings. How do I fix the
warnings that are in 3rd party libraries? How do I add type hints to code
Were any videos of the presentations made? Have they been uploaded anywhere
online? Sorry if this has been asked before I have tried searching.
regards,
Richard.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email
I actually just wrote a long reply detailing how to type hint 'this', and
then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole Cursive codebase, I can't figure it out either.
On 23 December 2013 01:03, Jim - Foo
Hmm, I see. get-distinct was returning an empty lazyseq, which apparently
made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
>
> Hmm, the different return types seem tied to the 2 different functions
> being called, but both functions have the same r
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.P
What I was getting at there was that it seems like nil could mean a leaf
node with the value nil or the absence of leaf nodes, and the two
situations can't be distinguished.
On Dec 22, 2013 12:26 PM, "Lee Spector" wrote:
>
> On Dec 22, 2013, at 12:02 PM, Micha Niskin wrote:
>
> > Also, what about
I am surprised that a map literal is clojure.lang.PersistentArrayMap but as
soon as I assign it to a var, it becomes clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions occur?
user> (type {})
clojure.lang.PersistentArrayMap
user> (type {:what "
On Dec 22, 2013, at 12:02 PM, Micha Niskin wrote:
> Also, what about this:
>
> (loop [z (zip/seq-zip '((nil) 0))]
> (if (zip/end? z)
> :done
> (do (println (zip/node z))
> (recur (zip/next z)
>
> Which produces:
>
> ((nil) 0)
> (nil)
> nil
> 0
> :done
I think that's ac
Also, what about this:
(loop [z (zip/seq-zip '((nil) 0))]
(if (zip/end? z)
:done
(do (println (zip/node z))
(recur (zip/next z)
Which produces:
((nil) 0)
(nil)
nil
0
:done
On Saturday, December 21, 2013 5:59:16 PM UTC-5, Lee wrote:
> On Dec 21, 2013, at 11:49 AM, Lee
Hi all,
is there any way to get rid of reflection in simmilar looking? Nothing
seems to work...
(proxy [JPanel ActionListener KeyListener] []
(paintComponent [^java.awt.Graphics g]
(let [^JPanel this this]
(proxy-super paintComponent g))
thanks in advance... :)
Jim
--
--
Yo
32 matches
Mail list logo
