Re: Calling an overloaded Scala function

2015-06-26 Thread Stephen Wakely
Sorry about the double threads - I messed up and thought the original post
didn't go through.

Looking further into this it seems in Java generics are largely a compile
time thing. The generic type information is wiped out from the type on
compile. So how does Java know which overload to call when the only
difference in the generic type of the parameter?

The answer is - it doesn't.

I whipped up a quick bit of Java to test this :



public static String Onk(ArrayListString str) {
System.out.println(string);
return ;
}

public static int Onk(ArrayListInteger it) {
System.out.println(int);
return 0;
}



This fails to compile :


Error:(11, 24) java: name clash:
Onk(java.util.ArrayListjava.lang.Integer) and
Onk(java.util.ArrayListjava.lang.String) have the same erasure




This sort of thing doesn't seem to be a problem for Scala, so it must be
doing something funky under the hood to resolve these methods.


Now, I can get the generic information about these methods using reflection
:

(- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
%))  pprint)

gives me :

([#ParameterizedTypeImpl
scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT,
  #ParameterizedTypeImpl com.cra.figaro.language.NameT,
  com.cra.figaro.language.ElementCollection]
 [#ParameterizedTypeImpl
scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT,
  #ParameterizedTypeImpl com.cra.figaro.language.NameT,
  com.cra.figaro.language.ElementCollection]


So in theory I think I should be able to hack something together to resolve
to the correct method. It won't be fast - or elegant, but hopefully it can
work.


Thanks




On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 That was meant as a response to the other thread.

 On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely 
 fungus.humun...@gmail.com wrote:


 So using reflection on the objects gives the following signatures -
 they have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it
 may change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit
 name: Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the
 other method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to 
 specify
 explicit type information about the collections. Consequently when 
 calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element

Re: Calling an overloaded Scala function

2015-06-26 Thread Stephen Wakely
I want to fully understand what is going on before doing anything.

Interestingly if I convert the Java code below to Scala it fails to compile
with the same error :

def Onk(str: util.ArrayList[String]): String = {
  println(String)
   erk
 }

 def Onk(it: util.ArrayList[Integer]): Integer = {
  println(Int)
   0
 }


But changing it to using (I think) more idiomatic Scala compiles and runs
fine.


 def Onk(str: (String)*): String = {
  println(String)
   erk
 }

 def Onk(it: (Integer)*): Integer = {
  println(Int)
   0
 }



On Fri, Jun 26, 2015 at 12:27 PM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Have you considered writing a wrapper method in Scala and calling that?

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 Sorry about the double threads - I messed up and thought the original
 post didn't go through.

 Looking further into this it seems in Java generics are largely a compile
 time thing. The generic type information is wiped out from the type on
 compile. So how does Java know which overload to call when the only
 difference in the generic type of the parameter?

 The answer is - it doesn't.

 I whipped up a quick bit of Java to test this :



 public static String Onk(ArrayListString str) {
 System.out.println(string);
 return ;
 }

 public static int Onk(ArrayListInteger it) {
 System.out.println(int);
 return 0;
 }



 This fails to compile :


 Error:(11, 24) java: name clash:
 Onk(java.util.ArrayListjava.lang.Integer) and
 Onk(java.util.ArrayListjava.lang.String) have the same erasure




 This sort of thing doesn't seem to be a problem for Scala, so it must be
 doing something funky under the hood to resolve these methods.


 Now, I can get the generic information about these methods using
 reflection :

 (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
 %))  pprint)

 gives me :

 ([#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]
  [#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]


 So in theory I think I should be able to hack something together to
 resolve to the correct method. It won't be fast - or elegant, but hopefully
 it can work.


 Thanks




 On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 That was meant as a response to the other thread.

 On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic
 types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely 
 fungus.humun...@gmail.com wrote:


 So using reflection on the objects gives the following signatures -
 they have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it
 may change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods 
 they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has

Re: Calling an overloaded Scala function

2015-06-25 Thread Stephen Wakely
Interesting. That could be a good last resort.

On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
wrote:

 Sorry, I do not know whether Clojure can or cannot determine the correct
 overload in this situation.

 All I have is a weak suggestion that work well enough: have you considered
 creating wrapper functions, e.g. in Scala or Java, that have different
 enough function signatures that Clojure can easily determine the correct
 one?

 Andy

 On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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


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

2015-06-25 Thread Stephen Wakely
So using reflection on the objects gives the following signatures - they
have identical signatures :

{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
 com.cra.figaro.language.Name
 com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
   {:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
 com.cra.figaro.language.Name
 com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}


On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala bytecode
 and figure out what the method signatures actually are. Or use Java
 reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen



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


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


Re: Calling an overloaded Scala function

2015-06-25 Thread Stephen Wakely
javap gives :

 public T com.cra.figaro.language.AtomicDistT
apply(scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);

  public T com.cra.figaro.language.CompoundDistT
apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);


Bit of an eyesore, but the two methods only differ in the generic types..

On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
wrote:


 So using reflection on the objects gives the following signatures - they
 have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
 wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala bytecode
 and figure out what the method signatures actually are. Or use Java
 reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen



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



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


Re: Calling an overloaded Scala function

2015-06-25 Thread Stephen Wakely
I am sadly quite clueless when it comes to Java.

De-compiling the Scala class file to Java gives me the following:

public T AtomicDistT apply(SeqTuple2Object, ElementT clauses,
NameT name, ElementCollection collection) {
return new AtomicDist(name, clauses.toList(), collection);

}



public T CompoundDistT apply(SeqTuple2ElementObject,
ElementT clauses, NameT name, ElementCollection collection) {


return new CompoundDist(name, clauses.toList(), collection);

}




Generics all over the place. Would this even be callable from Java 1.4?





On Thu, Jun 25, 2015 at 2:13 PM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Do you know how to call this method from Java 1.4? That will probably give
 enough context to use in Clojure type hints.

 Thanks,
 Ambrose

 On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 Interesting. That could be a good last resort.

 On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
 wrote:

 Sorry, I do not know whether Clojure can or cannot determine the correct
 overload in this situation.

 All I have is a weak suggestion that work well enough: have you
 considered creating wrapper functions, e.g. in Scala or Java, that have
 different enough function signatures that Clojure can easily determine the
 correct one?

 Andy

 On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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

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


  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure

Calling an overloaded Scala function

2015-06-25 Thread Stephen Wakely
I am trying to call into some Scala that has the following overloaded
methods :

  def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
collection: ElementCollection) =
new AtomicDist(name, clauses.toList, collection)

  def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
Name[T], collection: ElementCollection) =
new CompoundDist(name, clauses.toList, collection)

So one method takes a list of tuples of Double to Element and the other
method takes a list of tuples of Element to Element.

I am using t6.from-scala (https://github.com/t6/from-scala) to build up my
list of Tuples. But when building these up there is no way to specify
explicit type information about the collections. Consequently when calling
this apply method Clojure will always choose to call the first method -
even when my list is a collection of Element to Element tuples.

I can definitely appreciate how it is going to be tricky for Clojure to
determine the correct overload to use here. Is there any way I can somehow
force it to call the correct overload myself?


Thanks

Stephen

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


Calling an overloaded Scala function

2015-06-23 Thread Stephen Wakely
I am trying to call into some Scala that has the following overloaded
methods :

  def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
collection: ElementCollection) =
new AtomicDist(name, clauses.toList, collection)

  def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
Name[T], collection: ElementCollection) =
new CompoundDist(name, clauses.toList, collection)

So one method takes a list of tuples of Double to Element and the other
method takes a list of tuples of Element to Element.

I am using t6.from-scala (https://github.com/t6/from-scala) to build up my
list of Tuples. But when building these up there is no way to specify
explicit type information about the collections. Consequently when calling
this apply method Clojure will always choose to call the first method -
even when my list is a collection of Element to Element tuples.

I can definitely appreciate how it is going to be tricky for Clojure to
determine the correct overload to use here. Is there any way I can somehow
force it to call the correct overload myself?


Thanks

Stephen

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

2015-04-02 Thread Stephen Wakely
Instead of :

 (if (s1)

You just want :

 (if s1

s1 is a Long, not a function.


On Thu, Apr 2, 2015 at 8:56 AM michael zhuang zhuangdeyouxi...@gmail.com
wrote:

 : i'm new to clojure, when I try to implementation 'interleave', get error
 from type convertion java.lang。Long cannot be cast to clojure.lang.IFN.
 ; Now im reading stack trace, try to figure out what's going on..

 (defn myIL [col1 col2]
   (loop [m  []
  s1 (first col1)
  s2 (first col2)]
 (if (s1)
   m
   (recur (conj (conj m s1) s2)
  (first (next col1))
  (first (next col2)))
 )))

 (myIL [1 3] [2 4])

 Any helps ?

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


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


Re: Any Lispers in South Devon, UK?

2015-03-11 Thread Stephen Wakely
Superb! I will make sure I am there. Looking forward to it!

On Wed, Mar 11, 2015 at 9:56 PM Bruce Durling b...@otfrom.com wrote:

 w00t!

 On Wed, Mar 11, 2015 at 9:42 PM, John Kane j...@kanej.me wrote:
  Hello Stephen,
 
  Sorry for the late reply but we have been trying to get organised. The
  inaugural meeting of Exeter Clojurians will be:
 
  7pm Wednesday 25th March 2015
  City Gate Hotel, Iron Bridge, EX4 3RB
 
  Hope to see you there, and anyone else who is interested!
  John
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your
  first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you are subscribed to the Google Groups
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to clojure+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

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


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

2015-03-04 Thread Stephen Wakely
Awesome! I work in the middle of Exeter so that's definitely close enough.
I would love to get involved.

Do you guys have anything planned for a meet up?

On 4 Mar 2015 19:13, John Kane j...@kanej.me wrote:

 Hello Stephen,

 There is a small group of us based around Exeter and we are trying to get
 a group off the ground, is that close enough to be of interest?

 John

 On Tuesday, 3 March 2015 21:53:57 UTC, Stephen Wakely wrote:

 Hi,

 Are there any other Lispers in South Devon who would be interested in
 meeting up and talking code? Clojure, Common Lisp, Scheme, anything as long
 as there are loads of parentheses!

 Please get in touch.


 Cheers

 Stephen

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


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


Any Lispers in South Devon, UK?

2015-03-03 Thread Stephen Wakely
Hi,

Are there any other Lispers in South Devon who would be interested in 
meeting up and talking code? Clojure, Common Lisp, Scheme, anything as long 
as there are loads of parentheses!

Please get in touch.


Cheers

Stephen

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

2014-11-12 Thread Stephen Wakely
Interesting. I would definitely look into this if I ever need to do another
iOS app.

How does it work in a language without garbage collection? If you replace
an element in a vector and only keep a reference to the new vector there
will be a stray element there that would need mopping up. Is ARC clever
enough to recognise this? I wouldn't have thought so unless you maintain a
reference count for every element within the vector.. Which I don't imagine
would be particularly efficient.

On Wed, 12 Nov 2014 3:48 PM Anton Astashov anton.astas...@gmail.com wrote:

 Sorry for resurrecting of such an old post, but I just wrote port of
 Clojure's data structures in Objective-C -
 https://github.com/astashov/persistent.objc - hopefully one day someone
 will find that useful. :)

 On Sunday, March 31, 2013 5:43:52 AM UTC-7, Matthias Benkard wrote:

 I implemented persistent, array-mapped Patricia trees in C a while ago:

 https://matthias.benkard.de/journal/118

 It should be relatively straight-forward to build some Objective-C
 classes on top of that.  (There's a reason the memory management routines
 are named bpt_{retain, release, dealloc}. :))

 You'll just need to do the hashing yourself if you want to build a hash
 map.

 Matthias

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


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


Leiningen setup for modifying a library the project is depending on

2014-10-26 Thread Stephen Wakely
I need to make some modifications to a library that my project is depending on. 

Currently Leiningen downloads the lib from clojure and uses that lib.  Can I 
set things up so it uses the files I have cloned from github instead? 

I have searched the docs but can't find any ideas how to do this. 

Thanks 

Stephen 


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