Re: clojure.spec merge+or bug?

[shlomivaknin]

Thank you for explaining!

Just in case, I opened a bug here 
https://dev.clojure.org/jira/browse/CLJ-2388 

On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote:
>
> The non-flowing behavior on conform is expected behavior.
>
> Failure to roundtrip conform then unform is a bug (so I'd so the bug here 
> is in unform).
>
> On a quick search, I don't believe this was filed, but I could have missed 
> it.
>
> On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomi...@gmail.com 
>  wrote:
>>
>> Achhh, just spent the last few hours fighting this unexpected behavior 
>> with s/merge, until I finally came to realize that this is what it was..
>>
>> I see this thread is quite old, did anyone open a bug for it as mentioned 
>> above? 
>>
>> @Alex, you said this was the expected behavior, but then asked to open a 
>> bug because it does not round-trip.. I am slightly confused, does the 
>> problem lie in this "expected" behavior, or does it lie in s/unform? How 
>> would such a bug be closed?
>>
>> Thanks,
>> Shlomi
>>
>> On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>>>
>>> You can file a bug on the s/merge unform - anything that doesn't 
>>> roundtrip should be a bug.
>>>
>>> On the coll-of one, I thought that was just fixed in the latest 
>>> spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) - 
>>> are you using latest there?
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec merge+or bug?

[shlomivaknin]

Achhh, just spent the last few hours fighting this unexpected behavior with 
s/merge, until I finally came to realize that this is what it was..

I see this thread is quite old, did anyone open a bug for it as mentioned 
above? 

@Alex, you said this was the expected behavior, but then asked to open a 
bug because it does not round-trip.. I am slightly confused, does the 
problem lie in this "expected" behavior, or does it lie in s/unform? How 
would such a bug be closed?

Thanks,
Shlomi

On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>
> You can file a bug on the s/merge unform - anything that doesn't roundtrip 
> should be a bug.
>
> On the coll-of one, I thought that was just fixed in the latest spec.alpha 
> release (see https://dev.clojure.org/jira/browse/CLJ-2076) - are you 
> using latest there?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Cognitect acquired by Microsoft

[shlomivaknin]

Man, what a good one! You ruined me for a moment there :D

On Saturday, April 1, 2017 at 1:00:16 PM UTC-7, Gregg Reynolds wrote:
>
> made ya look!
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange problem with input stream starting clojure 1.7.0-alpha6

[shlomivaknin]

@Kevin, yes, I did just that to test coll-reduce, thanks for helping me out!

@Alex, thanks for the detailed response, it sure demystified this error and 
gave a bunch of different solutions, awesome!


On Monday, March 7, 2016 at 5:17:45 PM UTC-8, Alex Miller wrote:
>
> Iterator, seqs, and chunking is indeed the key to this issue. The change 
> in question is http://dev.clojure.org/jira/browse/CLJ-1669, which made 
> iterator-seq's chunked. In general, this should not be problematic with 
> most Java iterators, however there is a iterator implementation pattern 
> where the identical object is returned (and mutated) on every call to 
> next() on the iterator. This is done in Java for performance reasons 
> (reuses a single mutable object rather than creating N objects). Because 
> iterator-seq now chunks, it will obtain 32 elements at a time, but they 
> will all be the identical object, so you'll see the state of the 32'nd 
> object for all of them.
>
> iterator-seq intentionally does not handle this iterator pattern (this is 
> in the docstring and was introduced via 
> http://dev.clojure.org/jira/browse/CLJ-1738). 
>
> If you need to control iteration to one at a time (non-chunked), then 
> there are several options:
>
> 1. Use loop/recur and explicitly handle each object one at a time. Sounds 
> like you've got that one.
>
> 2. Implement your own lazy-seq that does not chunk.
>
> (defn iter-seq [iter f]
>   (if (.hasNext iter)
> (lazy-seq
>   (cons (f (.next iter))
> (iter-seq iter f)
>
> 3. Use transducers which will also pull a single element at a time in 
> current transducible contexts. If you want to use it as a seq, this means 
> invoking 
>
> (defn transform [^ArchiveRecord r]
>   (let [header (.getHeader r)
>  mime (.getMimetype header)]
> (if (plain-text? mime)
>   (println "got " (.available r)
>
> (defn mapper-map [this ^Text key warc-value ^MapContext context]
>   (sequence (map transform) warc-value))
>
> 4. In this particular case, since you're only doing side effects, 
> something like dorun would maybe be better.
>
> 5. (WARNING - may be removed!) You can still access the old iterator-seq 
> impementation in the Java impl for now:
>
> (clojure.lang.IteratorSeq/create iter)
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange problem with input stream starting clojure 1.7.0-alpha6

[shlomivaknin]

Thanks for your reply, 

ArchiveReader is actually an Iterator for ArchiveRecord 
(see 
https://github.com/iipc/webarchive-commons/blob/master/src/main/java/org/archive/io/ArchiveReader.java#L51).
 
I also tried to explicitly do (iterator-seq (.iterator warc-value)) but got 
the same "got 0" everywhere.

However, your remark about the lazy-seq was indeed very helpful. I tried to 
use a loop instead of doseq, and it did the trick!
I also succeeded in using coll-reduce instead of the explicit loop. 
However, it seems odd to use it, since I am really only doing a 
side-effecting loop (emitting key/values for hadoop's reducer) rather than 
making a transformation..

Is there a nicer (idiomatic core) way to treat non-chunk-able java 
iterables other than an explicit loop for side-effects?

Thanks!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Strange problem with input stream starting clojure 1.7.0-alpha6

[shlomivaknin]

Hey clojurians,

I am using a java library that reads WARC files (an internet archive 
format) to use with hadoop. 

I was recently motivated to upgrade this project's clojure from 1.6 to 1.8 
(to be able to use the recent (wonderful!) cider), and I got quite a 
strange behavior, that I managed to reduce to a simple example (on github 

)


(defn mapper-map [this ^Text key ^ArchiveReader warc-value ^MapContext 
context] (doseq [^ArchiveRecord r warc-value]
(let [header (.getHeader r)
mime (.getMimetype header)]
(if (plain-text? mime)
(println "got " (.available r))




Using any clojure version prior to 1.7.0-alpha6 (meaning, alpha5 and 
below), this code works great, and I get plenty of different "got %d" 
printed to the console with different sizes.

However, upgrading to 1.7.0-alpha6 and above, I am getting constant "got 0" 
for every record in the file, and nothing (obviously) gets computed.

I tried to see if I can find the culprit 
using 
https://github.com/clojure/clojure/compare/clojure-1.7.0-alpha5...clojure-1.7.0-alpha6
 
and couldnt find an obvious problem. I thought I might ask the list for 
pointers before I deep dive into this any further. 

If you wish to help with this problem by checking it on your machine, you 
could clone https://github.com/vadali/warc-cc/tree/upgrade-clojure (use 
upgrade-clojure branch), get the example file into the root dir of the 
cloned project using 

   s3cmd get 
s3://aws-publicdatasets/common-crawl/crawl-data/CC-MAIN-2013-48/segments/1387345775423/wet/CC-MAIN-20131218054935-00092-ip-10-33-133-15.ec2.internal.warc.wet.gz

and run using lein test warc-cc.example.

Thanks!


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-beta2

[shlomivaknin]

Right you are, silly me :)

thanks!

On Friday, May 1, 2015 at 11:17:42 AM UTC-7, Nicola Mometto wrote:
>
>
> The type-hint on init-state is wrong. 
>
> It has to be either 
>
> (defn {:tag 'longs} init-state [] (long-array 1)) 
> or (preferred) 
> (defn init-state ^longs [] (long-array 1)) 
>
>
> shlomi...@gmail.com  writes: 
>
> > I tried playing around with the new primitive type hints and got the 
> > following weird behavior on [org.clojure/clojure "1.7.0-beta2"]: 
> > 
> > (defn ^longs init-state []  (long-array 1)) 
> > 
> > (defn ^long store-state [^longs c ^long a] (aset c 0 a)) 
> > 
> > running the following line resulted in an exception: 
> > 
> > (let [x (init-state)] 
> >   (store-state x 5)) 
> > 
> > 1. Caused by java.lang.VerifyError 
> >(class: clojure_7/core$eval13270, method: invoke signature: 
> >()Ljava/lang/Object;) Unable to pop operand off an empty stack 
> > 
> > Class.java:   -2 
> >  java.lang.Class/getDeclaredConstructors0 
> > Class.java: 2671 
> >  java.lang.Class/privateGetDeclaredConstructors 
> > Class.java: 3075  java.lang.Class/getConstructor0 
> > Class.java:  412  java.lang.Class/newInstance 
> >  Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval 
> >  Compiler.java: 6791  clojure.lang.Compiler/eval 
> >  Compiler.java: 7237  clojure.lang.Compiler/load 
> >   REPL:1  reverse-index.main/eval13258 
> >  Compiler.java: 6792  clojure.lang.Compiler/eval 
> >  Compiler.java: 6755  clojure.lang.Compiler/eval 
> >   core.clj: 3079  clojure.core/eval 
> >   main.clj:  240 
>  clojure.main/repl/read-eval-print/fn 
> >   main.clj:  240  clojure.main/repl/read-eval-print 
> >   main.clj:  258  clojure.main/repl/fn 
> >   main.clj:  258  clojure.main/repl 
> >RestFn.java: 1523  clojure.lang.RestFn/invoke 
> > interruptible_eval.clj:   58 
> >  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn 
> >   AFn.java:  152  clojure.lang.AFn/applyToHelper 
> >   AFn.java:  144  clojure.lang.AFn/applyTo 
> >   core.clj:  628  clojure.core/apply 
> >   core.clj: 1866  clojure.core/with-bindings* 
> >RestFn.java:  425  clojure.lang.RestFn/invoke 
> > interruptible_eval.clj:   56 
> >  clojure.tools.nrepl.middleware.interruptible-eval/evaluate 
> > interruptible_eval.clj:  188 
> > 
>  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn 
> > interruptible_eval.clj:  157 
> >  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn 
> >   AFn.java:   22  clojure.lang.AFn/run 
> >ThreadPoolExecutor.java: 1142 
> >  java.util.concurrent.ThreadPoolExecutor/runWorker 
> >ThreadPoolExecutor.java:  617 
> >  java.util.concurrent.ThreadPoolExecutor$Worker/run 
> >Thread.java:  745  java.lang.Thread/run 
> > 
> > while the following line worked just fine: 
> > 
> > (store-state (init-state) 5) 
> > 
> > and also this works fine: 
> > 
> > (def a (init-state)) 
> > (store-state a 5) 
> > 
> > (aget a 0) ;; 5 
> > 
> > What do you think? 
> > 
> > On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote: 
> >> 
> >> Clojure 1.7.0-beta2 is now available. 
> >> 
> >> Try it via 
> >> - Download: 
> >> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/ 
> >> - Leiningen: [org.clojure/clojure "1.7.0-beta2"] 
> >> 
> >> Regression fixes since 1.7.0-beta1: 
> >> 
> >> 1) CLJ-1711 - structmap iterator broken 
> >> 2) CLJ-1709 - range wrong for step != 1 
> >> 3) CLJ-1713 - range chunks are not serializable 
> >> 4) CLJ-1698 - fix reader conditional bugs 
> >> 
> >> Additional enhancements to new features since 1.7.0-beta1: 
> >> 
> >> 1) CLJ-1703 - Pretty print #error and new public function 
> Throwable->map 
> >> 2) CLJ-1700 - Reader conditionals now allowed in the REPL 
> >> 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj 
> >> 
> >> For a full list of changes since 1.6.0, see: 
> >> https://github.com/clojure/clojure/blob/master/changes.md 
> >> 
> >> Please give it a try and let us know if things are working (or not)! 
> >> 
> >> - Alex 
> >> 
> >> 
>
> -- 
>

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

Re: [ANN] Clojure 1.7.0-beta2

[shlomivaknin]

I tried playing around with the new primitive type hints and got the 
following weird behavior on [org.clojure/clojure "1.7.0-beta2"]:

(defn ^longs init-state []  (long-array 1))

(defn ^long store-state [^longs c ^long a] (aset c 0 a))

running the following line resulted in an exception:

(let [x (init-state)]
  (store-state x 5))

1. Caused by java.lang.VerifyError
   (class: clojure_7/core$eval13270, method: invoke signature:
   ()Ljava/lang/Object;) Unable to pop operand off an empty stack

Class.java:   -2 
 java.lang.Class/getDeclaredConstructors0
Class.java: 2671 
 java.lang.Class/privateGetDeclaredConstructors
Class.java: 3075  java.lang.Class/getConstructor0
Class.java:  412  java.lang.Class/newInstance
 Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval
 Compiler.java: 6791  clojure.lang.Compiler/eval
 Compiler.java: 7237  clojure.lang.Compiler/load
  REPL:1  reverse-index.main/eval13258
 Compiler.java: 6792  clojure.lang.Compiler/eval
 Compiler.java: 6755  clojure.lang.Compiler/eval
  core.clj: 3079  clojure.core/eval
  main.clj:  240  clojure.main/repl/read-eval-print/fn
  main.clj:  240  clojure.main/repl/read-eval-print
  main.clj:  258  clojure.main/repl/fn
  main.clj:  258  clojure.main/repl
   RestFn.java: 1523  clojure.lang.RestFn/invoke
interruptible_eval.clj:   58 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
  AFn.java:  152  clojure.lang.AFn/applyToHelper
  AFn.java:  144  clojure.lang.AFn/applyTo
  core.clj:  628  clojure.core/apply
  core.clj: 1866  clojure.core/with-bindings*
   RestFn.java:  425  clojure.lang.RestFn/invoke
interruptible_eval.clj:   56 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:  188 
 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj:  157 
 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
  AFn.java:   22  clojure.lang.AFn/run
   ThreadPoolExecutor.java: 1142 
 java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  617 
 java.util.concurrent.ThreadPoolExecutor$Worker/run
   Thread.java:  745  java.lang.Thread/run

while the following line worked just fine:

(store-state (init-state) 5)

and also this works fine:

(def a (init-state))
(store-state a 5)

(aget a 0) ;; 5

What do you think?

On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote:
>
> Clojure 1.7.0-beta2 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
> - Leiningen: [org.clojure/clojure "1.7.0-beta2"]
>
> Regression fixes since 1.7.0-beta1:
>
> 1) CLJ-1711 - structmap iterator broken
> 2) CLJ-1709 - range wrong for step != 1
> 3) CLJ-1713 - range chunks are not serializable
> 4) CLJ-1698 - fix reader conditional bugs
>
> Additional enhancements to new features since 1.7.0-beta1:
>
> 1) CLJ-1703 - Pretty print #error and new public function Throwable->map
> 2) CLJ-1700 - Reader conditionals now allowed in the REPL
> 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj
>   
> For a full list of changes since 1.6.0, see:
> https://github.com/clojure/clojure/blob/master/changes.md
>
> Please give it a try and let us know if things are working (or not)!
>
> - Alex
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes

[shlomivaknin]

Hey, 
Just to be sure, are you loading the full uberjar to hadoop? 


On Wednesday, January 28, 2015 at 11:39:54 PM UTC-8, Jason Wolfe wrote:
>
> First off, I apologize in advance for not having a reduced test case, and 
> express my sincere gratitude in advance for any assistance.  I've been 
> tearing my hair out for a day or so and not making headway, and figured 
> someone here might recognize some keywords and have a pointer in the right 
> direction. (I'm admittedly pretty green when it comes to class loading, and 
> have largely exhausted my google fu).  
>
> *Problem: *
>
> I'm submitting a hadoop job using clojure-hadoop.  All is well with a 
> simple job, but once I require something that transitively depends on 
> Schema, I end up with: 
>
> clojure.lang.Compiler$CompilerException: 
> java.lang.IllegalArgumentException: No implementation of method: :walker of 
> protocol: #'schema.core/Schema found for class: clojure.core$long, 
> compiling:(crane/config.clj:33:4)
>
> It works fine when run in-process with hadoop-mapreduce-client-jobclient, 
> but not with bin/hadoop -jar.  This stunk of a classloader issue, and after 
> digging in it seems that there are multiple versions of clojure.core$long 
> floating around.  The version on which the protocol is extended is not the 
> same class for the fn that the symbol 'long resolves to in client code.
>
> *Context: *
>
> clojure-hadoop is AOT-compiled, and after being loaded by hadoop it 
> dynamically loads the target namespace (not AOT-compiled, nor any other of 
> the code in question) using 
> https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3
>
> From here, schema is transitively required, and then client namespaces 
> attempt to use the Schema protocol to generate validators, and when the 
> schema 'long is used (which resolves to the fn with class 
> clojure.core$long), it fails to find the appropriate method.  
>
> After repeated head-bashing, I've determined that there are (at least two) 
> versions of the clojure.core$long class floating around -- the one used to 
> extend the protocol, which stems from a DynamicClassLoader, and the one 
> that 'long resolves to in client code, which stems from a URLClassLoader. 
>  The URLClassLoader is the loader of the current thread and Compiler, but 
> not @(clojure.lang.Compiler/LOADER).
>
> *Attempts:*
>
> I've tried wrapping the clojure-hadoop loading code with 
> .setContextClassLoader on some obvious candidates and binding 
> *use-context-classloader* around the code doing the loading, with no avail. 
>  I've tried changing the schema code to reference the class in different 
> ways (class (resolve 'long)), (class 'long), etc and that hasn't made a 
> difference.  I've checked and the clojure-hadoop jar doesn't contain any 
> .class files for clojure, schema, or other offending code.  
>
> *Plea:*
>
> I suspect there's something obvious I'm missing.  (In retrospect it seems 
> like the design of Schema may be suboptimal in light of this, but if 
> possible I'd like to figure out a workaround without changing that 
> substantially). Thanks in advance for your help -- any and all pointers are 
> welcome.  
>
> -Jason
>
>
>
>  
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is Clojure fit for giant space-efficient in-memory tree structures?

[shlomivaknin]

I have done something quite similar, only that the structure consumed 
hundred of GB's of RAM and was the main bottleneck of the application. 
Attempting it on the jvm (either java or clojure) resulted in a lot of 
wasted bits per bits and GC hangs, so I tried to use ByteBuffers (Direct, 
Mapped, etc). I ended up writing the structure in C and exposing it to 
clojure via jni, thus reducing the heap size to the bare minimum and 
getting ultra fast performance with the convenience of clojure. 

Shlomi

On Friday, June 27, 2014 7:04:34 AM UTC+3, Vjeran Marcinko wrote:
>
> Hi,
>
> I am planning to play with implementing some giant in-memory index that is 
> basically tree-like structure containing counters on certain tree nodes, 
> and can aggregate billion data points and will probably consume tens of GBs 
> of RAM.
>
> Since space (memory)-efficiency is crucial here, I was wondering how good 
> Clojure is for this problem, and should I better just stick to plain java, 
> because it is well known that clojure's persistent data structures 
> sacrifice space (and some speed, but that is not such a big issue here) for 
> sake of immutability and good development practice?
>
> Regards,
> Vjeran
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: fast parallel reduction into hash-set/map

[shlomivaknin]

Hey Jules, 

Really nice stuff your making!
One note about your SuperVecs idea though, it seems that using that 
approach we could get a deeply nested tree to represent our a vector, and I 
think this is the exact thing vectors are trying to avoid.. 


On Friday, February 21, 2014 1:39:56 AM UTC+2, Jules wrote:
>
> Hi, Andy.
>
> No I haven't - Thanks for the pointer - I'll take a look.
>
> I have a very specific usecase - the speeding up of the re-combination of 
> the results of parallel reductions.
>
> I've found that the cost of this recombination often impacts badly on the 
> overall timing of such a reduction, but with a little thought we can speed 
> it up because we know that both seqs involved in the recombination are of 
> the same type...
>
> Given the proliferation of cores and FP's promise of simple and elegant 
> parallel code, I think that it is critical that Clojure really delivers on 
> this promise and this issue is the last blocker for me for a couple of 
> usecases that I have :-)
>
> I hope that explains where I am coming from - does it seem reasonable ? am 
> I missing anything ?
>
> thanks again,
>
>
> Jules
>   
>
> On Thursday, 20 February 2014 23:25:29 UTC, Andy Fingerhut wrote:
>>
>> Have you looked at core.rrb-vector, which implements Relaxed Radix Trees 
>> for vectors that implement subvec and concatenating two arbitrary vectors 
>> in O(log n) time?
>>
>> https://github.com/clojure/core.rrb-vector
>>
>> Unless I am missing something, the fast concatenation is what you are 
>> trying to achieve?
>>
>> Andy
>>
>>
>> On Thu, Feb 20, 2014 at 2:59 PM, Jules  wrote:
>>
>>>
>>> So, having broken the back of fast re-combination of hash sets and maps, 
>>> I wanted to take a look at doing a similar sort of thing for vectors - 
>>> another type of seq that I use very heavily in this sort of situation.
>>>
>>> Let's see the cake first:
>>>
>>> seqspert.vector=> (def a (into [] (range 1000)))
>>> #'seqspert.vector/a
>>> seqspert.vector=> (time (def b (into a a)))
>>> "Elapsed time: 3695.682654 msecs"
>>> #'seqspert.vector/b
>>> seqspert.vector=> (time (def c (supervec a a)))
>>> "Elapsed time: 0.253922 msecs"
>>> #'seqspert.vector/c
>>> seqspert.vector=> (= b c)
>>> true
>>>
>>> As you can see, the usual method of combining two vectors into a third 
>>> takes 3-4 secs to combine two 10M entry vectors.
>>>
>>> Using 'supervec' it takes MUCH less time.
>>>
>>> How ?
>>>
>>> I looked at vector's impl and quickly realised that I would not be able 
>>> to use the same trick that I had used for hash set/map. Then I looked at 
>>> subvec and realised that I could do a very similar trick to create supervec.
>>>
>>> Subvec provides a view on a subseq of a vector that behaves like a full 
>>> vector. Supervec provides a similar view that makes two vectors behave like 
>>> a single one:
>>>
>>> seqspert.vector=> (supervec [1 2 3] [4 5 6])
>>> [1 2 3 4 5 6]
>>> seqspert.vector=> (type (supervec [1 2 3] [4 5 6]))
>>> clojure.lang.APersistentVector$SuperVector
>>>
>>> We can use seqspert (see my other posting this evening) to look inside a 
>>> SuperVector:
>>>
>>> seqspert.vector=> (decloak (supervec [1 2 3] [4 5 6]))
>>> #seqspert.vector.SuperVector{:left #seqspert.vector.Vector{:cnt 3, 
>>> :shift 5, :root #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil]}, :tail [1 2 3]}, :right 
>>> #seqspert.vector.Vector{:cnt 3, :shift 5, :root 
>>> #seqspert.vector.VectorNode{:array [nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
>>> nil nil nil]}, :tail [4 5 6]}, :middle 3, :count 6}
>>> seqspert.vector=> (p/pprint (decloak (supervec [1 2 3] [4 5 6])))
>>> {:left
>>>  {:cnt 3,
>>>   :shift 5,
>>>   :root
>>>   {:array
>>>[nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil]},
>>>   :tail [1 2 3]},
>>>  :right
>>>  {:cnt 3,
>>>   :shift 5,
>>>   :root
>>>   {:array
>>>[nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil
>>> nil]},
>>>   :tail [4 5 6]},
>>>  :middle 3,
>>>  :count 6}
>>> nil
>>> seqspert.vector=> 
>>>
>>> It looks very complicated - that is the two clojurer vectors held inside 
>>> ! A SuperVector has fields left, right (the two vectors that we are 
>>

Re: question about let

[shlomivaknin]

hey, you could simply use do: 

(do (f1) (f2) (f3)) 

On Tuesday, November 5, 2013 2:18:56 AM UTC+2, julius wrote:
>
> Hi,
>
> I have a question, if there are a sequence of fn like (f1) (f2) (f3) ,I 
> just want to return the evaluation of last fn, for example
>
> ((f1)
>   (f2)
>   (f3))
>
> now I can do it by 
> (let []
>   (f1)
>(f2)
>(f3))
>
> I am not sure if there is another solution for it.
>
> Thanks  
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Functions using locks are slowed even when locks are never taken

[shlomivaknin]

same results on my machine as well.

I tried decompiling the jar (with cider-decompile), and the parts that 
actually run (the "then" clause) seems almost identical. If you'r 
interested, i can post them later tonight.

On Sunday, November 3, 2013 2:32:42 AM UTC+2, Michael Blume wrote:
>
> Hmm, it seems like if it were JIT related you'd see the same issue with 
> java code, but I get 5ns across the board.
>
>
> https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java
>
> On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote:
>>
>> Verified that I receive the same result patterns as you on my machine.
>>
>> One other possibility outside of what you have already mentioned would be 
>> something JIT-related.  Perhaps there is an optimization that can be 
>> performed if the locking sections of the code are in another function but 
>> otherwise no, but I'm not sure how that dovetails with Clojure' fn 
>> compilation.
>>
>> On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote:
>>>
>>> Since 1.6 alpha is out, I reran the tests with that -- basically the 
>>> same results.
>>>
>>> On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:

 https://github.com/MichaelBlume/perf-test

 (ns perf-test
   (:use (criterium core))
   (:gen-class))

 (def o (Object.))

 (defn foo [x]
   (if (> x 0)
 (inc x)
 (do
   (monitor-enter o)
   (let [res (dec x)]
 (monitor-exit 0)
 res

 (defn bar [x]
   (if (> x 0)
 (inc x)
 (dec x)))

 (defn locking-part [x l]
   (monitor-enter l)
   (let [res (dec x)]
 (monitor-exit l)
 res))

 (defn baz [x]
   (if (> x 0)
 (inc x)
 (locking-part x o)))

 (defn -main []
   (println "benching foo")
   (bench (foo 5) :verbose) 
   (println "benching bar")
   (bench (bar 5) :verbose)
   (println "benching baz")
   (bench (baz 5) :verbose)
   (println "done benching"))



 I'm only ever calling these functions with positive values, so the 
 monitor-enter branch should never be entered. Nevertheless, the 
 performance of foo is much worse than bar or baz.

 The best guess I've got is that the fact that lock-taking is involved 
 somehow changes how the function is compiled, somehow making the function 
 slower. If the practical upshot is that I shouldn't write functions that 
 only sometimes lock -- that the locking part of a function should always 
 be its own function -- then I can do that, but I'm curious why.

 $ lein uberjar
 Compiling perf-test
 Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
 Created 
 /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
 $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
 benching foo
 WARNING: Final GC required 1.5974571326266802 % of runtime
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 391582560 in 60 samples of 6526376 calls.
   Execution time sample mean : 167.426696 ns
  Execution time mean : 167.459429 ns
 Execution time sample std-deviation : 4.079466 ns
 Execution time std-deviation : 4.097819 ns
Execution time lower quantile : 160.742869 ns ( 2.5%)
Execution time upper quantile : 175.453376 ns (97.5%)
Overhead used : 1.634996 ns

 Found 2 outliers in 60 samples (3. %)
low-severe   2 (3. %)
  Variance from outliers : 12.5602 % Variance is moderately inflated by 
 outliers
 benching bar
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2174037300 in 60 samples of 36233955 calls.
   Execution time sample mean : 26.068923 ns
  Execution time mean : 26.066422 ns
 Execution time sample std-deviation : 0.887937 ns
 Execution time std-deviation : 0.916861 ns
Execution time lower quantile : 23.996763 ns ( 2.5%)
Execution time upper quantile : 27.911936 ns (97.5%)
Overhead used : 1.634996 ns

 Found 3 outliers in 60 samples (5. %)
low-severe   1 (1.6667 %)
low-mild 1 (1.6667 %)
high-mild1 (1.6667 %)
  Variance from outliers : 22.1874 % Variance is moderately inflated by 
 outliers
 benching baz
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2270676660 in 60 samples of 37844611 calls.
   Execution time sample mean : 25.834142 ns
  Execution time mean : 25.837429 ns
 Execution time sample std-deviation : 0.718382

Re: Clojure - Where to start?

[shlomivaknin]

Hey Jeff, 

On Thursday, October 10, 2013 11:41:05 PM UTC+2, Jeff Heon wrote:
>
> I remember reading a post with a list of open source projects with 
> excellent clojure code.


did you mean this post 
http://stackoverflow.com/questions/2444893/clojure-open-source-projects ? 

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

[shlomivaknin]

Hey, its been a while since this discussion ended.. 

I read through it and now i am fully confused, where did -?> and -?>> end 
up being in? 

Thanks,
Shlomi

On Thursday, April 21, 2011 5:51:59 PM UTC+3, Ivan Koblik wrote:
>
> Hi Paul,
>
> Thanks, good to know. Sorry for the misleading email.
>
> Cheers,
> Ivan.
>
>
> On 21 April 2011 08:47, pmbauer >wrote:
>
>> Ivan,
>> clojure/core use a different workflow than is typical for github
>> projects.
>> The github readme doesn't indicate, but you may find the process here:
>>
>> http://clojure.org/contributing
>> http://clojure.org/patches
>>
>> Cheers,
>> pm
>>
>> On Apr 20, 1:44 am, Ivan Koblik  wrote:
>> > Hello Konrad,
>> >
>> > Git workflow is a little bit different. You don't really need commit 
>> rights
>> > to contribute. I found a rather nice explanation of Git workflow here:
>> http://www.eqqon.com/index.php/Collaborative_Github_Workflow
>> >
>> > Hope it helps.
>> >
>> > Cheers,
>> > Ivan.
>> >
>> > On 19 April 2011 16:40, Konrad Hinsen  
>> wrote:
>> >
>> >
>> >
>> > > On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
>> >
>> > > >> Concerning my own modules in old contrib, there are three that I 
>> use
>> > > myself and that I am planning to maintain, independently of where 
>> they will
>> > > end up:
>> > > >> - clojure.contrib.monads
>> > > >> - clojure.contrib.macro-utils
>> > > >> - clojure.contrib.generic
>> >
>> > > > There is an empty repos already waiting for your macro utils:
>> > >https://github.com/clojure/tools.macro
>> >
>> > > Great, thanks, I'll start with that one. Monads depend on it anyway. 
>> But I
>> > > need commit permissions, which I probably don't have, but I don't 
>> even know
>> > > how to find out without trying to do a commit. Can you please add me 
>> in the
>> > > right place? My github account is khinsen.
>> >
>> > > > I have put some suggested names for the other new projects at
>> > >http://dev.clojure.org/display/design/Contrib+Library+Names. Please 
>> review
>> > > and comment, either there or here on the list.
>> >
>> > > It seems that for now the top-level namespaces (well, next-to-top) are
>> > > - clojure.core
>> > > - clojure.data
>> > > - clojure.java
>> > > - clojure.tools
>> >
>> > > I would like to suggest a new one, clojure.control, for control 
>> structures.
>> > > This would be the natural home for monads, but also for 
>> parallelization
>> > > frameworks and even for threading macros. None of this really fits 
>> into
>> > > "data" or "tools".
>> >
>> > > If the goal is to keep the number of top-level namespaces as small as
>> > > possible, I'd even propose to put clojure.contrib.generic under that 
>> label.
>> > > Otherwise, I'd propose yet another namespace, clojure.interfaces, 
>> where the
>> > > various submodules of generic would find their home next to other 
>> protocols
>> > > and interfaces of general interest.
>> >
>> > > Konrad.
>> >
>> > > --
>> > > 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 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

oh, right. thats a good point.

ill re-post that correction on the bug report.. thanks for the review!

On Wednesday, March 13, 2013 1:42:51 PM UTC+2, Marko Topolnik wrote:
>
> Hm. You shouldn't have made ConcreteChild a nested class, that is a 
> distraction that may set people on a wrong trail. In Java you are allowed 
> to have as many package-private classes as you wish; the constraint is only 
> on one *public* class. If you had ConcreteChild.java with this in it:
>
> abstract class AbstractParent {
> public final int x() { return 6; }
> }
>
> public class ConcreteChild extends AbstractParent {}
>
> it would have compiled.
>
> On Wednesday, March 13, 2013 12:16:10 PM UTC+1, shlomi...@gmail.com wrote:
>>
>> here is the bug report: http://dev.clojure.org/jira/browse/CLJ-1183
>>
>> Thanks!
>>
>> On Wednesday, March 13, 2013 1:02:25 PM UTC+2, shlomi...@gmail.com wrote:
>>>
>>> right, i managed to reproduce it here, thanks!
>>>
>>> so i am opening a bug and linking back here
>>>
>>> On Wednesday, March 13, 2013 12:48:43 PM UTC+2, Marko Topolnik wrote:

 Yes, the error is there. I also created a *lein new app* project, 
 which by default creates a gen-classed main namespace:

 (ns call-test.core (:gen-class))
 (set! *warn-on-reflection* true)
 (defn -main [& args] (.x (test.ConcreteChild.)))

 Now try *lein do clean, uberjar. *It will report a reflection warning 
 while AOT-compiling. 

 Then do *java -jar target/call-test-0.1.0-SNAPSHOT-standalone.jar *and 
 see it fail.

 This cleanly separates compile time from runtime.

 On Wednesday, March 13, 2013 11:44:05 AM UTC+1, shlomi...@gmail.comwrote:
>
> very interesting.. are you getting the same error as i originally got?
>
> On Wednesday, March 13, 2013 12:38:26 PM UTC+2, Marko Topolnik wrote:
>>
>> Detailed finding: it *doesn't* fail at compile time; it always fails 
>> at runtime.
>>
>> Reason: at compile time there is a *reflection warning*, which means 
>> that the method wasn't found and a reflective call was emited by the 
>> compiler.
>>
>> On Wednesday, March 13, 2013 11:31:08 AM UTC+1, Marko Topolnik wrote:
>>>
>>> I did it: the method must be final. Apparently without that the 
>>> child is compiled with an overriding method that I didn't even define!
>>>
>>> On Wednesday, March 13, 2013 11:27:55 AM UTC+1, Marko Topolnik wrote:

 You should first make a minimal example that reproduces this. I've 
 just failed to do so with the following:

 abstract class AbstractParent {
 public void x() { System.out.println("x"); }
 }

 public class ConcreteChild extends AbstractParent {
 }

 user> (set! *warn-on-reflection* true)
 true
 user> (.x (test.ConcreteChild.))
 nil
 user> (.x ^test.AbstractParent (test.ConcreteChild.))
 nil
 user> (def cc (test.ConcreteChild.))
 #'user/cc
 user> (.x cc)
 Reflection warning, NO_SOURCE_PATH:1:1 - reference to field x can't 
 be resolved.
 nil
 user> 

 What must I add to break it?

>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

here is the bug report: http://dev.clojure.org/jira/browse/CLJ-1183

Thanks!

On Wednesday, March 13, 2013 1:02:25 PM UTC+2, shlomi...@gmail.com wrote:
>
> right, i managed to reproduce it here, thanks!
>
> so i am opening a bug and linking back here
>
> On Wednesday, March 13, 2013 12:48:43 PM UTC+2, Marko Topolnik wrote:
>>
>> Yes, the error is there. I also created a *lein new app* project, which 
>> by default creates a gen-classed main namespace:
>>
>> (ns call-test.core (:gen-class))
>> (set! *warn-on-reflection* true)
>> (defn -main [& args] (.x (test.ConcreteChild.)))
>>
>> Now try *lein do clean, uberjar. *It will report a reflection warning 
>> while AOT-compiling. 
>>
>> Then do *java -jar target/call-test-0.1.0-SNAPSHOT-standalone.jar *and 
>> see it fail.
>>
>> This cleanly separates compile time from runtime.
>>
>> On Wednesday, March 13, 2013 11:44:05 AM UTC+1, shlomi...@gmail.comwrote:
>>>
>>> very interesting.. are you getting the same error as i originally got?
>>>
>>> On Wednesday, March 13, 2013 12:38:26 PM UTC+2, Marko Topolnik wrote:

 Detailed finding: it *doesn't* fail at compile time; it always fails 
 at runtime.

 Reason: at compile time there is a *reflection warning*, which means 
 that the method wasn't found and a reflective call was emited by the 
 compiler.

 On Wednesday, March 13, 2013 11:31:08 AM UTC+1, Marko Topolnik wrote:
>
> I did it: the method must be final. Apparently without that the child 
> is compiled with an overriding method that I didn't even define!
>
> On Wednesday, March 13, 2013 11:27:55 AM UTC+1, Marko Topolnik wrote:
>>
>> You should first make a minimal example that reproduces this. I've 
>> just failed to do so with the following:
>>
>> abstract class AbstractParent {
>> public void x() { System.out.println("x"); }
>> }
>>
>> public class ConcreteChild extends AbstractParent {
>> }
>>
>> user> (set! *warn-on-reflection* true)
>> true
>> user> (.x (test.ConcreteChild.))
>> nil
>> user> (.x ^test.AbstractParent (test.ConcreteChild.))
>> nil
>> user> (def cc (test.ConcreteChild.))
>> #'user/cc
>> user> (.x cc)
>> Reflection warning, NO_SOURCE_PATH:1:1 - reference to field x can't 
>> be resolved.
>> nil
>> user> 
>>
>> What must I add to break it?
>>
>>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

right, i managed to reproduce it here, thanks!

so i am opening a bug and linking back here

On Wednesday, March 13, 2013 12:48:43 PM UTC+2, Marko Topolnik wrote:
>
> Yes, the error is there. I also created a *lein new app* project, which 
> by default creates a gen-classed main namespace:
>
> (ns call-test.core (:gen-class))
> (set! *warn-on-reflection* true)
> (defn -main [& args] (.x (test.ConcreteChild.)))
>
> Now try *lein do clean, uberjar. *It will report a reflection warning 
> while AOT-compiling. 
>
> Then do *java -jar target/call-test-0.1.0-SNAPSHOT-standalone.jar *and 
> see it fail.
>
> This cleanly separates compile time from runtime.
>
> On Wednesday, March 13, 2013 11:44:05 AM UTC+1, shlomi...@gmail.com wrote:
>>
>> very interesting.. are you getting the same error as i originally got?
>>
>> On Wednesday, March 13, 2013 12:38:26 PM UTC+2, Marko Topolnik wrote:
>>>
>>> Detailed finding: it *doesn't* fail at compile time; it always fails at 
>>> runtime.
>>>
>>> Reason: at compile time there is a *reflection warning*, which means 
>>> that the method wasn't found and a reflective call was emited by the 
>>> compiler.
>>>
>>> On Wednesday, March 13, 2013 11:31:08 AM UTC+1, Marko Topolnik wrote:

 I did it: the method must be final. Apparently without that the child 
 is compiled with an overriding method that I didn't even define!

 On Wednesday, March 13, 2013 11:27:55 AM UTC+1, Marko Topolnik wrote:
>
> You should first make a minimal example that reproduces this. I've 
> just failed to do so with the following:
>
> abstract class AbstractParent {
> public void x() { System.out.println("x"); }
> }
>
> public class ConcreteChild extends AbstractParent {
> }
>
> user> (set! *warn-on-reflection* true)
> true
> user> (.x (test.ConcreteChild.))
> nil
> user> (.x ^test.AbstractParent (test.ConcreteChild.))
> nil
> user> (def cc (test.ConcreteChild.))
> #'user/cc
> user> (.x cc)
> Reflection warning, NO_SOURCE_PATH:1:1 - reference to field x can't be 
> resolved.
> nil
> user> 
>
> What must I add to break it?
>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

very interesting.. are you getting the same error as i originally got?

On Wednesday, March 13, 2013 12:38:26 PM UTC+2, Marko Topolnik wrote:
>
> Detailed finding: it *doesn't* fail at compile time; it always fails at 
> runtime.
>
> Reason: at compile time there is a *reflection warning*, which means that 
> the method wasn't found and a reflective call was emited by the compiler.
>
> On Wednesday, March 13, 2013 11:31:08 AM UTC+1, Marko Topolnik wrote:
>>
>> I did it: the method must be final. Apparently without that the child is 
>> compiled with an overriding method that I didn't even define!
>>
>> On Wednesday, March 13, 2013 11:27:55 AM UTC+1, Marko Topolnik wrote:
>>>
>>> You should first make a minimal example that reproduces this. I've just 
>>> failed to do so with the following:
>>>
>>> abstract class AbstractParent {
>>> public void x() { System.out.println("x"); }
>>> }
>>>
>>> public class ConcreteChild extends AbstractParent {
>>> }
>>>
>>> user> (set! *warn-on-reflection* true)
>>> true
>>> user> (.x (test.ConcreteChild.))
>>> nil
>>> user> (.x ^test.AbstractParent (test.ConcreteChild.))
>>> nil
>>> user> (def cc (test.ConcreteChild.))
>>> #'user/cc
>>> user> (.x cc)
>>> Reflection warning, NO_SOURCE_PATH:1:1 - reference to field x can't be 
>>> resolved.
>>> nil
>>> user> 
>>>
>>> What must I add to break it?
>>>


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

That is very true.

is here the right place? is there a a different group/forum for the 
language developers? should i file a bug on github?

On Wednesday, March 13, 2013 12:17:45 PM UTC+2, Marko Topolnik wrote:
>
> The netty people are not to blame; harass Rich instead :)
>
> On Wednesday, March 13, 2013 11:11:46 AM UTC+1, shlomi...@gmail.com wrote:
>>
>> hmmm, that what i was afraid of :)
>> ill take my chances harassing the netty people now before i go down that 
>> path..
>>
>> On Wednesday, March 13, 2013 12:09:44 PM UTC+2, Marko Topolnik wrote:
>>>
>>> I see, that's very unfortunate then. It fails even when it is not 
>>> actually making the reflective call. Your last recourse is writing your own 
>>> code against the Java Reflection API, using *setAccesible(true)* if 
>>> necessary.
>>>
>>> On Wednesday, March 13, 2013 11:03:50 AM UTC+1, shlomi...@gmail.comwrote:

 I fully agree with you, only it doesnt work.. ServerBootstrap does not 
 override that specific method, which is what causing this pain, so i dont 
 know what other options i have.

 here is my attempt:

 user> (.channel ^ServerBootstrap b ^Class 
 io.netty.channel.socket.nio.NioServerSocketChannel)
 Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be 
 resolved.
 IllegalArgumentException Can't call public method of non-public class: 
 public io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)



 On Wednesday, March 13, 2013 11:58:06 AM UTC+2, Marko Topolnik wrote:
>
> It does have a public descendant, though. It is not acceptable for you 
> to annotate with ServerBootstrap? It really is bad practice to annotate 
> with non-public classes.
>
> On Wednesday, March 13, 2013 10:43:35 AM UTC+1, shlomi...@gmail.comwrote:
>>
>> hey
>> we dont need to be almost certain, we can just look at the code : 
>> https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
>>  and 
>> see that it is not a public ancestor. more then that, i annotated the 
>> code 
>> and it didnt work. here is a repl dump, same as Sean did:
>>
>> ; nREPL 0.1.6-preview
>> user> (set! *warn-on-reflection* true) 
>> true
>> user> (import '(io.netty.bootstrap AbstractBootstrap 
>> ServerBootstrap)) 
>> io.netty.bootstrap.ServerBootstrap
>> user> (def b (ServerBootstrap.)) 
>> #'user/b
>> user> (.channel ^AbstractBootstrap b ^Class 
>> io.netty.channel.socket.nio.NioServerSocketChannel) 
>> Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be 
>> resolved.
>> IllegalArgumentException Can't call public method of non-public 
>> class: public io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
>>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)
>> user>  *clojure-version* 
>> {:major 1, :minor 5, :incremental 1, :qualifier nil}
>>
>>
>>
>> On Wednesday, March 13, 2013 11:34:33 AM UTC+2, Marko Topolnik wrote:
>>>
>>> It is almost certain that the method you want to call is inherited 
>>> from a public ancestor. Annotate the call with that ancestor and it 
>>> will 
>>> work.
>>>
>>> On Wednesday, March 13, 2013 10:23:31 AM UTC+1, 
>>> shlomi...@gmail.comwrote:

 here is the full exception when compiling:

 Exception in thread "main" java.lang.IllegalArgumentException: 
 Can't call public method of non-public class: public 
 io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class), 
 compiling:(netty.clj:31:1)
 at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1453)
 at clojure.lang.Compiler.compile1(Compiler.java:7153)
 at clojure.lang.Compiler.compile(Compiler.java:7219)

 Caused by: java.lang.IllegalArgumentException: Can't call public 
 method of non-public class: public 
 io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)


 On Wednesday, March 13, 2013 11:21:40 AM UTC+2, 
 shlomi...@gmail.comwrote:
>
> yes you are right, it is a compile-time error.. 
>
> On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik 
> wrote:
>>
>> When you annotate, is it a runtime or a compile-time error? I 
>> would be very surprised if it happened at runtime (when the function 
>> is 
>> actuall called).
>>
>> On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin 
>> wrote:
>>>
>>> hey, I have a 

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

hmmm, that what i was afraid of :)
ill take my chances harassing the netty people now before i go down that 
path..

On Wednesday, March 13, 2013 12:09:44 PM UTC+2, Marko Topolnik wrote:
>
> I see, that's very unfortunate then. It fails even when it is not actually 
> making the reflective call. Your last recourse is writing your own code 
> against the Java Reflection API, using *setAccesible(true)* if necessary.
>
> On Wednesday, March 13, 2013 11:03:50 AM UTC+1, shlomi...@gmail.com wrote:
>>
>> I fully agree with you, only it doesnt work.. ServerBootstrap does not 
>> override that specific method, which is what causing this pain, so i dont 
>> know what other options i have.
>>
>> here is my attempt:
>>
>> user> (.channel ^ServerBootstrap b ^Class 
>> io.netty.channel.socket.nio.NioServerSocketChannel)
>> Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be 
>> resolved.
>> IllegalArgumentException Can't call public method of non-public class: 
>> public io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
>>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)
>>
>>
>>
>> On Wednesday, March 13, 2013 11:58:06 AM UTC+2, Marko Topolnik wrote:
>>>
>>> It does have a public descendant, though. It is not acceptable for you 
>>> to annotate with ServerBootstrap? It really is bad practice to annotate 
>>> with non-public classes.
>>>
>>> On Wednesday, March 13, 2013 10:43:35 AM UTC+1, shlomi...@gmail.comwrote:

 hey
 we dont need to be almost certain, we can just look at the code : 
 https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
  and 
 see that it is not a public ancestor. more then that, i annotated the code 
 and it didnt work. here is a repl dump, same as Sean did:

 ; nREPL 0.1.6-preview
 user> (set! *warn-on-reflection* true) 
 true
 user> (import '(io.netty.bootstrap AbstractBootstrap ServerBootstrap)) 
 io.netty.bootstrap.ServerBootstrap
 user> (def b (ServerBootstrap.)) 
 #'user/b
 user> (.channel ^AbstractBootstrap b ^Class 
 io.netty.channel.socket.nio.NioServerSocketChannel) 
 Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be 
 resolved.
 IllegalArgumentException Can't call public method of non-public class: 
 public io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)
 user>  *clojure-version* 
 {:major 1, :minor 5, :incremental 1, :qualifier nil}



 On Wednesday, March 13, 2013 11:34:33 AM UTC+2, Marko Topolnik wrote:
>
> It is almost certain that the method you want to call is inherited 
> from a public ancestor. Annotate the call with that ancestor and it will 
> work.
>
> On Wednesday, March 13, 2013 10:23:31 AM UTC+1, shlomi...@gmail.comwrote:
>>
>> here is the full exception when compiling:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Can't 
>> call public method of non-public class: public 
>> io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class), 
>> compiling:(netty.clj:31:1)
>> at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1453)
>> at clojure.lang.Compiler.compile1(Compiler.java:7153)
>> at clojure.lang.Compiler.compile(Compiler.java:7219)
>>
>> Caused by: java.lang.IllegalArgumentException: Can't call public 
>> method of non-public class: public io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)
>>
>>
>> On Wednesday, March 13, 2013 11:21:40 AM UTC+2, shlomi...@gmail.comwrote:
>>>
>>> yes you are right, it is a compile-time error.. 
>>>
>>> On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:

 When you annotate, is it a runtime or a compile-time error? I would 
 be very surprised if it happened at runtime (when the function is 
 actuall 
 called).

 On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
>
> hey, I have a similar problem, even when i type annotate with 
> clojure 1.5 i still get that error.. any suggestions?
>


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

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

I fully agree with you, only it doesnt work.. ServerBootstrap does not 
override that specific method, which is what causing this pain, so i dont 
know what other options i have.

here is my attempt:

user> (.channel ^ServerBootstrap b ^Class 
io.netty.channel.socket.nio.NioServerSocketChannel)
Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be resolved.
IllegalArgumentException Can't call public method of non-public class: 
public io.netty.bootstrap.AbstractBootstrap 
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
 clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)



On Wednesday, March 13, 2013 11:58:06 AM UTC+2, Marko Topolnik wrote:
>
> It does have a public descendant, though. It is not acceptable for you to 
> annotate with ServerBootstrap? It really is bad practice to annotate with 
> non-public classes.
>
> On Wednesday, March 13, 2013 10:43:35 AM UTC+1, shlomi...@gmail.com wrote:
>>
>> hey
>> we dont need to be almost certain, we can just look at the code : 
>> https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
>>  and 
>> see that it is not a public ancestor. more then that, i annotated the code 
>> and it didnt work. here is a repl dump, same as Sean did:
>>
>> ; nREPL 0.1.6-preview
>> user> (set! *warn-on-reflection* true) 
>> true
>> user> (import '(io.netty.bootstrap AbstractBootstrap ServerBootstrap)) 
>> io.netty.bootstrap.ServerBootstrap
>> user> (def b (ServerBootstrap.)) 
>> #'user/b
>> user> (.channel ^AbstractBootstrap b ^Class 
>> io.netty.channel.socket.nio.NioServerSocketChannel) 
>> Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be 
>> resolved.
>> IllegalArgumentException Can't call public method of non-public class: 
>> public io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
>>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)
>> user>  *clojure-version* 
>> {:major 1, :minor 5, :incremental 1, :qualifier nil}
>>
>>
>>
>> On Wednesday, March 13, 2013 11:34:33 AM UTC+2, Marko Topolnik wrote:
>>>
>>> It is almost certain that the method you want to call is inherited from 
>>> a public ancestor. Annotate the call with that ancestor and it will work.
>>>
>>> On Wednesday, March 13, 2013 10:23:31 AM UTC+1, shlomi...@gmail.comwrote:

 here is the full exception when compiling:

 Exception in thread "main" java.lang.IllegalArgumentException: Can't 
 call public method of non-public class: public 
 io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class), 
 compiling:(netty.clj:31:1)
 at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1453)
 at clojure.lang.Compiler.compile1(Compiler.java:7153)
 at clojure.lang.Compiler.compile(Compiler.java:7219)

 Caused by: java.lang.IllegalArgumentException: Can't call public method 
 of non-public class: public io.netty.bootstrap.AbstractBootstrap 
 io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)


 On Wednesday, March 13, 2013 11:21:40 AM UTC+2, shlomi...@gmail.comwrote:
>
> yes you are right, it is a compile-time error.. 
>
> On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:
>>
>> When you annotate, is it a runtime or a compile-time error? I would 
>> be very surprised if it happened at runtime (when the function is 
>> actuall 
>> called).
>>
>> On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
>>>
>>> hey, I have a similar problem, even when i type annotate with 
>>> clojure 1.5 i still get that error.. any suggestions?
>>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

hey
we dont need to be almost certain, we can just look at the code : 
https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
 and 
see that it is not a public ancestor. more then that, i annotated the code 
and it didnt work. here is a repl dump, same as Sean did:

; nREPL 0.1.6-preview
user> (set! *warn-on-reflection* true) 
true
user> (import '(io.netty.bootstrap AbstractBootstrap ServerBootstrap)) 
io.netty.bootstrap.ServerBootstrap
user> (def b (ServerBootstrap.)) 
#'user/b
user> (.channel ^AbstractBootstrap b ^Class 
io.netty.channel.socket.nio.NioServerSocketChannel) 
Reflection warning, NO_SOURCE_PATH:1:1 - call to channel can't be resolved.
IllegalArgumentException Can't call public method of non-public class: 
public io.netty.bootstrap.AbstractBootstrap 
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
 clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)
user>  *clojure-version* 
{:major 1, :minor 5, :incremental 1, :qualifier nil}



On Wednesday, March 13, 2013 11:34:33 AM UTC+2, Marko Topolnik wrote:
>
> It is almost certain that the method you want to call is inherited from a 
> public ancestor. Annotate the call with that ancestor and it will work.
>
> On Wednesday, March 13, 2013 10:23:31 AM UTC+1, shlomi...@gmail.com wrote:
>>
>> here is the full exception when compiling:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Can't call 
>> public method of non-public class: public 
>> io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class), 
>> compiling:(netty.clj:31:1)
>> at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1453)
>> at clojure.lang.Compiler.compile1(Compiler.java:7153)
>> at clojure.lang.Compiler.compile(Compiler.java:7219)
>>
>> Caused by: java.lang.IllegalArgumentException: Can't call public method 
>> of non-public class: public io.netty.bootstrap.AbstractBootstrap 
>> io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)
>>
>>
>> On Wednesday, March 13, 2013 11:21:40 AM UTC+2, shlomi...@gmail.comwrote:
>>>
>>> yes you are right, it is a compile-time error.. 
>>>
>>> On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:

 When you annotate, is it a runtime or a compile-time error? I would be 
 very surprised if it happened at runtime (when the function is actuall 
 called).

 On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
>
> hey, I have a similar problem, even when i type annotate with clojure 
> 1.5 i still get that error.. any suggestions?
>


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

here is the full exception when compiling:

Exception in thread "main" java.lang.IllegalArgumentException: Can't call 
public method of non-public class: public 
io.netty.bootstrap.AbstractBootstrap 
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class), 
compiling:(netty.clj:31:1)
at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1453)
at clojure.lang.Compiler.compile1(Compiler.java:7153)
at clojure.lang.Compiler.compile(Compiler.java:7219)
at clojure.lang.RT.compile(RT.java:398)
at clojure.lang.RT.load(RT.java:438)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5018.invoke(core.clj:5530)
at clojure.core$load.doInvoke(core.clj:5529)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5336)
at clojure.core$compile$fn__5023.invoke(core.clj:5541)
at clojure.core$compile.invoke(core.clj:5540)
at user$eval7.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6619)
at clojure.lang.Compiler.eval(Compiler.java:6609)
at clojure.lang.Compiler.eval(Compiler.java:6582)
at clojure.core$eval.invoke(core.clj:2852)
at clojure.main$eval_opt.invoke(main.clj:308)
at clojure.main$initialize.invoke(main.clj:327)
at clojure.main$null_opt.invoke(main.clj:362)
at clojure.main$main.doInvoke(main.clj:440)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: Can't call public method of 
non-public class: public io.netty.bootstrap.AbstractBootstrap 
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)


On Wednesday, March 13, 2013 11:21:40 AM UTC+2, shlomi...@gmail.com wrote:
>
> yes you are right, it is a compile-time error.. 
>
> On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:
>>
>> When you annotate, is it a runtime or a compile-time error? I would be 
>> very surprised if it happened at runtime (when the function is actuall 
>> called).
>>
>> On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
>>>
>>> hey, I have a similar problem, even when i type annotate with clojure 
>>> 1.5 i still get that error.. any suggestions?
>>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

yes you are right, it is a compile-time error.. 

On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:
>
> When you annotate, is it a runtime or a compile-time error? I would be 
> very surprised if it happened at runtime (when the function is actuall 
> called).
>
> On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
>>
>> hey, I have a similar problem, even when i type annotate with clojure 1.5 
>> i still get that error.. any suggestions?
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

Hey Sean,

Your attempt worked because in Netty 4.0.0.Alpha8 
AbstractBootstrap
 was 
still  public.. Try it out with 4.0.0.Beta2..

Thanks!

On Wednesday, March 13, 2013 4:15:51 AM UTC+2, Sean Corfield wrote:
>
> On Tue, Mar 12, 2013 at 5:46 PM,  > 
> wrote: 
> > In my case i am trying to get clojure working with netty 4, here is the 
> > code: 
> > 
> > (def #^AbstractBootstrap b (ServerBootstrap.)) 
> > (.channel ^AbstractBootstrap b ^Class 
> > io.netty.channel.socket.nio.NioServerSocketChannel) 
> > 
> > which returns the error: 
> > java.lang.IllegalArgumentException: Can't call public method of 
> non-public 
> > class: public io.netty.bootstrap.AbstractBootstrap 
> > io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class) 
> >  at clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88) 
>
> I can't reproduce this (with Clojure 1.5.1, Netty 4.0.0.Alpha8): 
>
> user=> (set! *warn-on-reflection* true) 
> true 
> user=> (import '(io.netty.bootstrap AbstractBootstrap ServerBootstrap)) 
> io.netty.bootstrap.ServerBootstrap 
> user=> (def b (ServerBootstrap.)) 
> #'user/b 
> user=> (.channel ^AbstractBootstrap b ^Class 
> io.netty.channel.socket.nio.NioServerSocketChannel) 
> # 
> user=> *clojure-version* 
> {:major 1, :minor 5, :incremental 1, :qualifier nil} 
> user=> 
>
>
> Can you provide more detail? 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Java interop: "Can't call public method of non-public class"

[shlomivaknin]

I meant to post this as a reply 
to https://groups.google.com/d/msg/clojure/jYfEKVH5GsQ/3Hq5hU0u6UQJ

In my case i am trying to get clojure working with netty 4, here is the 
code:

(def #^AbstractBootstrap b (ServerBootstrap.)) 
(.channel 
^AbstractBootstrapb
 ^Class io.netty.channel.socket.nio.NioServerSocketChannel)  

which returns the error:
java.lang.IllegalArgumentException: Can't call public method of non-public 
class: public io.netty.bootstrap.AbstractBootstrap 
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class)  
 at clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:88)  

why does it still use the reflector even though its fully annotated, and 
how do i get over that non-public class issue?..

On Wednesday, March 13, 2013 2:26:00 AM UTC+2, Shlomi Vaknin wrote:
>
> hey, I have a similar problem, even when i type annotate with clojure 1.5 
> i still get that error.. any suggestions?
>

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

[shlomivaknin]

Hey Daniel,

are you making a clojure-israel google group?


On Monday, December 17, 2012 12:58:21 PM UTC+2, Daniel Szmulewicz wrote:
>
> Hi everybody, 
>
> Happy to announce that Israel has its first Clojure user group.
>
> http://www.meetup.com/Clojure-Israel/
>
> Sincerely,
>
> Daniel Szmulewicz
>

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