[ANN] A post on CLJS DOM manipulation libraries

[Dave Della Costa]

Hi folks,

Albeit a little later than I'd hoped, I've written a post giving a
high-level overview of the DOM manipulation/Event handling libraries
available in ClojureScript at the present time:

http://davedellacosta.com/cljs-dom-survey

It's aimed at beginners in ClojureScript, for the most part, but may be
useful to anyone who isn't familiar with the DOM libraries out there and
their relative merits.

If I've forgotten anything or made any mistakes, or otherwise have
comments, please drop me a line.

Thank you!

Best,
Dave

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: loop/recur with multiple branches

[Vincent Chen]

On Tue, Dec 10, 2013 at 11:46 PM, Cedric Greevey  wrote:
> On Tue, Dec 10, 2013 at 6:29 PM, Vincent Chen  wrote:
>>
>> Try this (not tested, might be missing parens and whatnot):
>>
>> (defn slice [x s n]
>>   (loop [[h & tail] x, s s, n n, acc []]
>> (cond
>>   (zero? n) acc
>>   (zero? s) (recur tail s (dec n) (conj acc h))
>>   :else (recur tail (dec s) n acc
>>
>> Few notes:
>> - When trying for tail recursions, use an accumulator. The accumulator
>> carries the eventual result, which is returned at the base case.
>> - Since we're destructuring into head and tail, I used vectors. conj
>> will push to the end of the vector.
>> - In Clojure, vectors tend to be more natural than lists. Accumulating
>> into lists usually requires a reverse in the base case.
>
>
> If you're going to go with vectors, why not go transient as well?
>
Ah. I've read about them, but have never used them before myself. Thanks.

By the way, my reply wasn't directed at you. I didn't know that you
had already answered his questions until after I had sent mine :)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.

Should I be using deftype, gen-class or defrecord instead of this hack?

[Tim]

As an experiment, I've written a DSL that generates database queries using 
*effectively* only the data. The query logic is derived from the data 
assemblance and choice of data structures (or types). I am at the stage 
where I have all the logic working, and I am now moving into perf testing 
and tuning. BUT, before I do, there's this one hack I have implemented that 
has me asking the this question.

As I wrote the DSL I ran out of data structure types to account for a few 
defined meanings within the query logic. As a short term hack I decided to 
attach meta data to symbols where the meta data contained a data value 
along with, for example, a sort option. I only intended for this to be 
short term until I got around to figuring out the semantics of Clojure's 
deftype or defrecord.

Here's the hack:

  (defn object [v m]
(let [id (gensym #"object#")]
  (with-meta id
(merge m {:default v :id id}


  (defn object? [o]
(if-let [it (meta o)]
   (if (= (it :id) o)
  true false)
   false))

  (defn inspect
([o]
  (inspect o nil))
([o & xs]
  (if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
   (if (coll? x)
   (select-keys it x)
   (x it))
it)
  
(defn instance
  ([o]
(instance o nil))
  ([o & args]
(if-let [it (meta o)]
   (if (= (:id it) o)
   (if-let [x (:default it)]
 (if (fn? x)
 (if-let [args (or (and (some identity args) args) (it 
:args))]
   (apply x args)
   (x))
  x)
  it)


  => (def o (object #(java.util.UUID/randomUUID){:sort '>})
  object#24397 
 
  => (object? o))
  true

  => (instance o) 
  #uuid "3c9cca8b-59e2-46b2-9175-468de3a21a22"

  => (inspect o :sort)) 
  >

So now I've been reading up on Clojure's deftypes & defrecords and while it 
I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to my 
hack. Am I missing something? Is this a case where you wouldn't be caught 
dead using the above hack? Why or why not?  

As I see it: I'm not creating and/or holding millions of objects that would 
need to be shared, altered or held onto. These have relatively short lives 
that only serve in compiling to a different query language. Type hints or 
java interop really shouldn't matter.

Notes: 

1. While the above function names may carry OO concepts, these functions 
are not intended to fulfil all of them them; rather they only fill a 
specific functionality gap that appears to meet my needs.
2. I realize one wouldn't sort on a UUID, it's just an example to show the 
functionality. :)


Thanks,
Tim

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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] introduction to opencv development with clojure

[Colin Fleming]

Congratulations Mimmo, that's great news. I'd like to play with OpenCV at
some point, I'll definitely use this if/when I do. And yes, I totally agree
- Seesaw is the gold standard with lib wrapping IMO, it's a fantastic piece
of work.

Cheers,
Colin


On 12 December 2013 08:00, Mimmo Cosenza  wrote:

> Hi all,
> I'm happy to announce that a first tutorial on introducing OpenCV
> development with clojure has been just merged in the official 2.4
> documentation branch
>
>
> https://github.com/Itseez/opencv/blob/2.4/doc/tutorials/introduction/clojure_dev_intro/clojure_dev_intro.rst
>
> It's only the a very initial step, but my intention is to go on with the
> computer vision stuff. Eventually I'll ask some suggestion for implementing
> a seesaw GUI comparable to the current OpenCV Qt GUI.
>
> Seesaw seems to me even a great example on how to wrap an OO lib to make
> it usable in a more functional way.
>
> The REPL interactivity seems to really add some value in learning and
> experimenting OpenCV. Another step I have in mind is to create a Chrome
> Native Extension which use the OpenCV c/c++ lib for intensive calculation
> and ClojureScript for the visualizations, but it's only just a very draft
> idea.
>
> I don't know how much time I could spend in the few month on modern-cljs
> series of tutorials, but I promise that I'll do my best to keep it going
>
> My best
>
> 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.

Re: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time

[Alexey Verkhovsky]

A couple of updates on things that were discussed earlier. 

1. Thanks to this thread we are now talking to quite a few awesome people 
from North America. So, not everyone able and willing to write Clojure on 
the day job has this wish fulfilled, after all :)

2. We are not doing H1Bs/relocations for the time being. Actually, the 
point of remote pairing is to be able to hire masters without geography 
constraints, while pairing solves most of the usual problems associated 
with remote work.

--Alex

On Sunday, 17 November 2013 17:39:24 UTC-7, Alexey Verkhovsky wrote:
>
> Hello, all,
>
> I'm a Clojure noob (half way through Stu Halloway's book), who's just 
> joined this group today. Sorry about my first post being a recruitment 
> spam. Seeing that there aren't that many yet, I hope nobody minds. For the 
> right kind of people (talented, pragmatic and not averse to full-time 
> pairing), this is a great gig.
>
> I'm hoping to contribute to this community in some more meaningful ways in 
> the near future :)
>
>
> Please reply to me off list. A link to your Github profile counts for much 
> more than a stellar resume. Doesn't have to be in Clojure.
>
> --Alex Verkhovsky
>
>
> --
>
>
> Outpace Systems, Inc is hiring!
>
>
>- 
>
>Polyglot lifestyle ~ currently Clojure,Ruby, CoffeeScript
>- 
>
>100% pairing using remote tools
>- 
>
>Very competitive pay
>- 
>
>Work from anywhere in the US
>- 
>
>Very agile - fast, flexible teams with world class business architects 
>and programmers
>
>
> We are an early stage SW product company doing its first client 
> engagement. The company was founded in February, and has been profitable 
> since early May. The domain is enterprise software, but with a few twists 
> that we think are real game-changers. We are only hiring master programmers 
> and very strong journeymen. We pay extremely competitively, work in cool 
> technologies, and have already hired a great team that we are looking to 
> expand.
>
> We are committed to a polyglot lifestyle and an emphasis on truly fast 
> flexible teams. The only guiding principles on the developer side are near 
> 100% pair programming, strong focus on testing, and continuous integration. 
> We are currently using primarily Clojure, Ruby, and CoffeeScript - but we 
> hire strong programmers no matter what language they are currently fluent 
> in.
>
> Geographically, we are only hiring in the US time zones for the time being 
> - it's just too hard to pair across a lot of  time zones. Our primary 
> working environment is a Macbook pro, two thunderbolt monitors on your 
> desktop at home using screensharing to do remote pairing. 
>
> We are minimizing travel and relocation so that we can hire the best 
> people anywhere on the continent. If we have the necessity and opportunity 
> to travel, we let people decide for themselves whether they want to be 
> involved. If you don’t want to travel at all, we still want to talk to you. 
>
> The company is on track to make $6 million in revenue this year, with 
> expectations of over $15 million next year, and we need the best 
> programmers we can get to make that happen. Two of the founders are ex 
> McKinsey & Company, including an ex senior partner who started doing Agile 
> in 1992 (winning the ComputerWorld Best Business application of IT award) 
> with an approach called "Do it fix it rapid prototyping".
>
> Let us know if you are interested!
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: implementing arithmetic operators without using [+ - * / even? odd? inc dec]

[u1204]

Implement the nand function, simulate registers using nand,
and you can do anything since nand is universal. Or, if you
really want to get primitive write a turing tape processor.
Pain all the way down :-)

Tim Daly

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: type-hinting functions with variable (but known) return types

[Cedric Greevey]

The only thing I can think of off the top of my head is to write a
hinted-array macro that turns (hinted-array Class expr) into ^Class
(into-array Class expr). Emitting type hints or other form metadata in
macros is do-able, but sometimes a bit tricky. Something like this might
work (untested):

(defmacro hinted-array [class expr]
  (with-meta
`(into-array ~class ~expr)
{:tag class}))



On Wed, Dec 11, 2013 at 12:04 PM, Phillip Lord  wrote:

>
> Sorry, full of questions about type hinting at the moment.
>
> I've found myself writing a lot of expressions like this:
>
> ^"[Lorg.semanticweb.owlapi.model.OWLClassExpression;"
> (into-array OWLClassExpression
> [(ensure-class o name)
>  (ensure-class o disjoint)])
>
> Now the strange thing here is that I have to type hint an expression
> which clojure clearly knows the return type of (although only for the
> expression and not for the function).
>
> This is particularly painful because I'm only constructing the array to
> call a variadic method in Java, and the type hint is particularly
> verbose.
>
> Is there an easier way?
>
> 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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] introduction to opencv development with clojure

[Mimmo Cosenza]

Hi all,
I'm happy to announce that a first tutorial on introducing OpenCV development 
with clojure has been just merged in the official 2.4 documentation branch

https://github.com/Itseez/opencv/blob/2.4/doc/tutorials/introduction/clojure_dev_intro/clojure_dev_intro.rst

It's only the a very initial step, but my intention is to go on with the 
computer vision stuff. Eventually I'll ask some suggestion for implementing a 
seesaw GUI comparable to the current OpenCV Qt GUI. 

Seesaw seems to me even a great example on how to wrap an OO lib to make it 
usable in a more functional way. 

The REPL interactivity seems to really add some value in learning and 
experimenting OpenCV. Another step I have in mind is to create a Chrome Native 
Extension which use the OpenCV c/c++ lib for intensive calculation and 
ClojureScript for the visualizations, but it's only just a very draft idea. 

I don't know how much time I could spend in the few month on modern-cljs series 
of tutorials, but I promise that I'll do my best to keep it going

My best

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: T-shirts?

[Aaron Brooks]

Out of curiosity, who is behind
ClojureAppreciation?
(i.e Who gets the ~21% markup?)

If this is Rich and/or Tom, I'm more than glad to pay $37 for a t-shirt. If
it's a for-profit entity (such as Cognitect), I think the price is a bit
extravagant (personally... which you can ignore :) ). I just want to know
where the money is going.

In any case, thanks for making these available!

-A.

On Mon, Nov 25, 2013 at 11:31 AM, Rich Hickey  wrote:

> Official T shirts are finally available!
>
> http://clojure.org/swag
>
> Thanks for your support,
>
> Rich
>
> On Jul 29, 2013, at 5:27 PM, s...@ummon.com wrote:
>
> > Speaking as the person who "made" the 'Clojure = Simplicity'
> hoody/t-shirt, I am more than happy to assign it to the clojure community
> if wanted. I created it a while back as I couldn't find any. I will also
> gladly donate my zazzle balance (all $8.12 of it) from the sales :)
> >
> > Regards
> > S.
> >
> >  Original Message 
> > Subject: Re: T-shirts?
> > From: James Rothering 
> > Date: Mon, July 29, 2013 5:16 pm
> > To: clojure@googlegroups.com
> >
> > +1 I'll buy, too.
> >
> >
> > On Mon, Jul 29, 2013 at 1:38 PM, Joel Holdbrooks 
> wrote:
> > +1. I'd love this.
> >
> > On Sunday, July 28, 2013 3:22:21 PM UTC-7, Isaac Wagner wrote:
> > There was a discussion a while ago about stickers which led to
> http://clojure.org/swag. Could we get some sanctioned T-shirts as well?
> There are a few Clojure shirts on Zazzle, but what I would be interested in
> is some black, grey, and white shirts with nothing but a big Clojure logo
> on the front and I would love to buy them in a way that supports Clojure.
> >
> > Isaac
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from 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.
> >
> >
> >
> >
> >
> > --
> > Regards,
> >
> > James Rothering
> > 
> > (Msg) 206-888-1776
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from 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
Groups "Clojure" group.
To post to this group, send email to clo

Re: 'neostore' does not contain a store version, please ensure that the original database was shut down in a clean state.

[Joseph Guhlin]

I just want to fully agree with Wes, don't run this from eclipse. I get 
best performance from Neo4j batch inserter by compiling it and then running 
it from the jar, as opposed to lein run.

Definitely check your heap to the JVM and to the batchinserter 
initialization, as they are separate and it can take awhile to process and 
store all of that onto a hard drive.

--Joseph

On Wednesday, December 11, 2013 10:40:51 AM UTC-6, Wes Freeman wrote:
>
> The alternatives to BatchInserter are to just use the normal Java API and 
> batch things up into large transactions--~10k things at a time is probably 
> a good first try. You'll probably get 1/4 to 1/2 of the speed of the batch 
> inserter, but it won't crash unrecoverably, as the journal file will be 
> written. Usually, if you have your records somewhere you can retrieve them 
> again, the risk of the unsafe aspect of BatchInserter are mitigated, and 
> the speed is worth it. 
>
> As a side note, you should probably not be running this sort of thing in 
> an IDE. Make sure you have configured enough RAM for the BatchInserter mmio 
> options--that is a key way to make performance a lot faster.
>
> Wes
>
> On Wed, Dec 11, 2013 at 12:07 AM, Himakshi Mangal 
> 
> > wrote:
>
>> Hi wes,
>>
>> I tried with neo4j-shell but it gave me this error: 
>> Error starting org.neo4j.kernel.EmbeddedGraphDatabase, 
>> /home/himakshi/work/setup/neo4j-community-2.0.0-RC1/bin/../data/dbpedia.db
>>
>> Yes, I am using org.neo4j.unsafe.BatchInserter. 
>>
>> If this causes the problem, can there be any alternate solution because i 
>> cannot afford to loose my db after 3-lakhs records are already processed.
>>
>>
>>
>>
>> On Tuesday, December 10, 2013 3:30:09 PM UTC+5:30, Himakshi Mangal wrote:
>>
>>> Hi,
>>>
>>> I was using clojure to upload the dbpedia datasets into neo4j.
>>>
>>> Unfortunately, my system hanged and i had to restart everything. Now, if 
>>> i start the execution of program again it shows this error:
>>>
>>> 'neostore' does not contain a store version, please ensure that the 
>>> original database was shut down in a clean state.
>>>
>>>
>>> How can i solve this error so that i can start the uploading from the 
>>> point it stopped?
>>>
>>> Please help
>>>
>>  -- 
>> -- 
>> 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.

Re: type hinting overloaded methods

[Phillip Lord]

Mikera  writes:

> On Wednesday, 11 December 2013 14:50:36 UTC, Phillip Lord wrote:
> Macros that generate type hints can get pretty ugly. 

Yes, I notice that!

> I ran into the same problem with vectorz-clj
>
> The following pattern ended up working for me: the trick to to create a 
> local symbol that you can tag
>
> (defmacro tag-symbol [tag form]
>   (let [tagged-sym (vary-meta (gensym "res") assoc :tag tag)]
> `(let [~tagged-sym ~form] ~tagged-sym)))


Will try, thanks for the pointer!

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.

type-hinting functions with variable (but known) return types

[Phillip Lord]

Sorry, full of questions about type hinting at the moment.

I've found myself writing a lot of expressions like this:

^"[Lorg.semanticweb.owlapi.model.OWLClassExpression;"
(into-array OWLClassExpression
[(ensure-class o name)
 (ensure-class o disjoint)])

Now the strange thing here is that I have to type hint an expression
which clojure clearly knows the return type of (although only for the
expression and not for the function).

This is particularly painful because I'm only constructing the array to
call a variadic method in Java, and the type hint is particularly
verbose.

Is there an easier way?

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.

Re: 'neostore' does not contain a store version, please ensure that the original database was shut down in a clean state.

[Wes Freeman]

The alternatives to BatchInserter are to just use the normal Java API and
batch things up into large transactions--~10k things at a time is probably
a good first try. You'll probably get 1/4 to 1/2 of the speed of the batch
inserter, but it won't crash unrecoverably, as the journal file will be
written. Usually, if you have your records somewhere you can retrieve them
again, the risk of the unsafe aspect of BatchInserter are mitigated, and
the speed is worth it.

As a side note, you should probably not be running this sort of thing in an
IDE. Make sure you have configured enough RAM for the BatchInserter mmio
options--that is a key way to make performance a lot faster.

Wes

On Wed, Dec 11, 2013 at 12:07 AM, Himakshi Mangal  wrote:

> Hi wes,
>
> I tried with neo4j-shell but it gave me this error:
> Error starting org.neo4j.kernel.EmbeddedGraphDatabase,
> /home/himakshi/work/setup/neo4j-community-2.0.0-RC1/bin/../data/dbpedia.db
>
> Yes, I am using org.neo4j.unsafe.BatchInserter.
>
> If this causes the problem, can there be any alternate solution because i
> cannot afford to loose my db after 3-lakhs records are already processed.
>
>
>
>
> On Tuesday, December 10, 2013 3:30:09 PM UTC+5:30, Himakshi Mangal wrote:
>
>> Hi,
>>
>> I was using clojure to upload the dbpedia datasets into neo4j.
>>
>> Unfortunately, my system hanged and i had to restart everything. Now, if
>> i start the execution of program again it shows this error:
>>
>> 'neostore' does not contain a store version, please ensure that the
>> original database was shut down in a clean state.
>>
>>
>> How can i solve this error so that i can start the uploading from the
>> point it stopped?
>>
>> Please help
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: type hinting overloaded methods

[Mikera]

On Wednesday, 11 December 2013 14:50:36 UTC, Phillip Lord wrote:
>
> Mikera > writes: 
>
> > On Wednesday, 11 December 2013 13:37:24 UTC, Philipp Meier wrote: 
> >> Implementing a clojure protocol will give you fast dispatch on the 
> first 
> >> argument's type. 
> >> 
> > 
> > Very true... it's a tradeoff: 
> > - protocols allow open extension (which doesn't appear to be needed 
> here?) 
> > - instance? checks are even faster (although protocol dispatch is still 
> > pretty fast) 
> > - protocols have some other quirks (e.g. not allowing primitive 
> arguments) 
> > 
> > In the case we have here (a small fixed number of types, no open 
> dispatch 
> > required) I think I would prefer instance? checks (especially given a 
> nice 
> > macro to remove the boilerplate). 
>
>
> Yeah, unfortunately I do need dispatch on primitive arguments, so 
> protocols fail for me. 
>
> I've been trying to get this to work as a macro, but am having problems 
> with this. The instance? check is easy to do, but adding the type hint 
> is much harder; I think that the ^macro expands at read time, so before 
> the macro expands, so it's not possible to construct the type hint. 
>
> I've tried to rewrite this with `with-meta' but can't get this to work 
> either since I think the meta is being added to the value. 
>
> My hope was to get something like this... 
>
> (defn ^IRI iri 
>   [name] 
>   (with-type-hint 
>  [name [String java.net.URL java.io.File]] 
>  (IRI/create name))) 
>
> Am I really the first person to get this problem? 
>
> Phil 
>

Macros that generate type hints can get pretty ugly. I ran into the same 
problem with vectorz-clj

The following pattern ended up working for me: the trick to to create a 
local symbol that you can tag

(defmacro tag-symbol [tag form]
  (let [tagged-sym (vary-meta (gensym "res") assoc :tag tag)]
`(let [~tagged-sym ~form] ~tagged-sym)))


 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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 can't import some Java classes

[Robin Heggelund Hansen]

Is this something that is fixable?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: type hinting overloaded methods

[Phillip Lord]

Mikera  writes:

> On Wednesday, 11 December 2013 13:37:24 UTC, Philipp Meier wrote:
>> Implementing a clojure protocol will give you fast dispatch on the first 
>> argument's type. 
>>
>
> Very true... it's a tradeoff:
> - protocols allow open extension (which doesn't appear to be needed here?)
> - instance? checks are even faster (although protocol dispatch is still 
> pretty fast)
> - protocols have some other quirks (e.g. not allowing primitive arguments)
>
> In the case we have here (a small fixed number of types, no open dispatch 
> required) I think I would prefer instance? checks (especially given a nice 
> macro to remove the boilerplate). 


Yeah, unfortunately I do need dispatch on primitive arguments, so
protocols fail for me.

I've been trying to get this to work as a macro, but am having problems
with this. The instance? check is easy to do, but adding the type hint
is much harder; I think that the ^macro expands at read time, so before
the macro expands, so it's not possible to construct the type hint.

I've tried to rewrite this with `with-meta' but can't get this to work
either since I think the meta is being added to the value.

My hope was to get something like this...

(defn ^IRI iri 
  [name]
  (with-type-hint
 [name [String java.net.URL java.io.File]]
 (IRI/create name)))

Am I really the first person to get this problem?

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.

Re: type hinting overloaded methods

[Mikera]

On Wednesday, 11 December 2013 13:37:24 UTC, Philipp Meier wrote:
>
> Hi,
>
> Am Mittwoch, 11. Dezember 2013 14:27:01 UTC+1 schrieb Mikera:
>>
>> You can't really avoid the instance checks: the underlying mechanic is 
>> that the JVM needs to figure out somehow at runtime which overloaded method 
>> version to call, since all it knows at compile time is that it has an 
>> arbitrary Object. 
>>
>> instance? is the simplest way to do this. There are some fancier ways 
>> (e.g. using reflection or invokedynamic) but your case doesn't have very 
>> complex dispatch requirements so instance? checks are almost certainly the 
>> best option.
>>
>> The good news is that instance? checks are extremely fast on the JVM so 
>> performance will still be great (certainly far better than if you used any 
>> kind of reflection)
>>
>
> Implementing a clojure protocol will give you fast dispatch on the first 
> argument's type. 
>

Very true... it's a tradeoff:
- protocols allow open extension (which doesn't appear to be needed here?)
- instance? checks are even faster (although protocol dispatch is still 
pretty fast)
- protocols have some other quirks (e.g. not allowing primitive arguments)

In the case we have here (a small fixed number of types, no open dispatch 
required) I think I would prefer instance? checks (especially given a nice 
macro to remove the boilerplate). 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: type hinting overloaded methods

[Philipp Meier]

Hi,

Am Mittwoch, 11. Dezember 2013 14:27:01 UTC+1 schrieb Mikera:
>
> You can't really avoid the instance checks: the underlying mechanic is 
> that the JVM needs to figure out somehow at runtime which overloaded method 
> version to call, since all it knows at compile time is that it has an 
> arbitrary Object. 
>
> instance? is the simplest way to do this. There are some fancier ways 
> (e.g. using reflection or invokedynamic) but your case doesn't have very 
> complex dispatch requirements so instance? checks are almost certainly the 
> best option.
>
> The good news is that instance? checks are extremely fast on the JVM so 
> performance will still be great (certainly far better than if you used any 
> kind of reflection)
>

Implementing a clojure protocol will give you fast dispatch on the first 
argument's type. 

-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.

Re: type hinting overloaded methods

[Mikera]

You can't really avoid the instance checks: the underlying mechanic is that 
the JVM needs to figure out somehow at runtime which overloaded method 
version to call, since all it knows at compile time is that it has an 
arbitrary Object. 

instance? is the simplest way to do this. There are some fancier ways (e.g. 
using reflection or invokedynamic) but your case doesn't have very complex 
dispatch requirements so instance? checks are almost certainly the best 
option.

The good news is that instance? checks are extremely fast on the JVM so 
performance will still be great (certainly far better than if you used any 
kind of reflection)


On Tuesday, 10 December 2013 10:25:48 UTC, Phillip Lord wrote:
>
>
>
> I want to type hint an overloaded Java method. I used to have a function 
> like so 
>
> (defn iri [name] 
>  (IRI/create name)) 
>
> Where IRI.create is one of 
>
> IRI.create(String) 
> IRI.create(URL) 
> IRI.create(File) 
>
> Type hinting the return value of this is straight-forward, but the 
> parameter is one of three types. The only way I seem to be able to get 
> this to work is to do lots of instance? checks... 
>
>
> (defn ^IRI iri 
>   [name] 
>   (cond 
>(instance? String name) 
>(IRI/create ^String name) 
>(instance? java.net.URL name) 
>(IRI/create ^java.net.URL name) 
>(instance? java.io.File name) 
>(IRI/create ^java.io.File name))) 
>
> which is a lot longer and, well, just not very nice. I could make this 
> neater with a macro -- something like... 
>
> (with-types [String, URL, File] 
>(IRI/create name)) 
>
> which would expand into the cond form above. But the instance? checks 
> seem not ideal. Is there a better solution? 
>
> 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.

Re: Big Excel (xlsx) file parsing (docjure, incanter...)

[Ragnar Dahlén]

Have you tried increasing the heap size of your JVM using the -Xmx and -Xms 
options? 

We're loading some spreadsheets that are 80M in size and have to run with a 
~1.5G heap to handle this...

On Saturday, 7 September 2013 02:22:27 UTC+1, Stanislav Sobolev wrote:
>
> Hello guys. I have excel file with huge columns in there.
> When i used some plugin(docjure, or anything else) it shows 
> me CompilerException java.lang.OutOfMemoryError: Java heap space, compiling
> How can i handle that big file without converting it to csv? 
> Primary problem in xlsx structure, it doesnt have lines or something, 
> unlike csv.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Code layout

[Cedric Greevey]

On Wed, Dec 11, 2013 at 2:00 AM, Mark Engelberg wrote:

> Put as much as is legible on one line.  If you need to break lines, break
> after the function name, not after the first parameter, in order to
> minimize rightward drift.
>

I've always preferred

(map foo
  coll1
  coll2)

over breaking after "map", and a few similar cases with HOFs whose first
parameter is a function. It always "feels" to me that "map foo" in its
entirety is a kind of operator (although the bare "map" also is, at the
same time) and the intent is clearer if it's not split up internally.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.