Third Brick Wall

[Alessio Stalla]

Arrays are primitive sequences of fixed size and element type. They are
implemented in the JVM itself (presumably in C++). Each array has a
(synthetic) array class represented in Java as <type>[].class, e.g.,
int[].class or String[].class or Object[][].class.
Lists are higher-level data structures, implemented in Java. They're
potentially heterogeneous in element type, have variable size, and several
implementations with different characteristics, particularly wrt.
performance and concurrency. ArrayList is one such implementation: a List
backed by a primitive array. Then there's LinkedList, etc.

On Mon, 27 Jul 2020 at 06:14, Steven Nunez <steve_nunez at yahoo.com> wrote:

> The jlist-from-list works fine, thank you.
>
> More generally, I think much of the confusion is that a Lisper will enter
> into the FFI with a certain set of assumptions that don't hold. An array is
> a type of list?
>
>
> What's the basis for thinking this?
>
>
> In an earlier message you wrote "*Since Java.util.List is abstract,  you
> need to choose a concrete class, such as ArrayList.*" I took this to mean
> that there was an is-a relationship between Array and List.
>
> No Array class? Only specific types of array classes (e.g. array of Int)?
>
>
> Not following. It would be useful for us if you to unpack how someone
> would come to these conclusions. We could  make the documentation better so
> as to try to avoid the confusion.
>
> This came about when I searched for Array classes and a stack overflow
> discussion
> <https://stackoverflow.com/questions/8546500/why-isnt-there-a-java-lang-array-class-if-a-java-array-is-an-object-shouldnt>
> seemed to suggest "There *are* array classes, one per element type used
> in the program" along with some other information that probably confused
> me further.
>
> What helped was when I realised that java.lang.list is probably like a
> lisp *sequence *and although perhaps not a direct superclass, may act
> like one. I still could be wrong, but it helped me conceptualise things
> enough to 'solve' the problem.
>
> I've put what I've learned so far into an annotated hello-world.lisp
> <https://github.com/Symbolics/Spark.cl/blob/master/hello-world.lisp> on
> github so that it can be turned into a tutorial when it's finished. It's a
> work in progress, but by the end of the Spark hello world, I hope that most
> of the basics will have been demonstrated. The code is almost certainly not
> yet a good exemplar, and would benefit greatly from a review by someone(s)
> more knowledgeable about ABCL than I.
>
>
> On Sunday, July 26, 2020, 6:37:27 AM GMT+8, Alan Ruttenberg <
> alanruttenberg at gmail.com> wrote:
>
>
>
>
> On Sat, Jul 25, 2020 at 5:15 AM Steven Nunez <steve_nunez at yahoo.com>
> wrote:
>
> Thanks Alan. What finally worked is:
>
> (#"parallelize" *sc* (#"asList" 'Arrays (java:jarray-from-list '(1 2 3 4
> 5))))
>
>
> Did you try the code I sent to create the list? Here it is rephrased to be
> analogous to jarrary-from-list
>
> (defun jlist-from-list (list)
>   (let ((jlist (jss::new 'arraylist)))
>     (loop for el in list
>           do (#"add" jlist el))
>     jlist))
>
> I would expect to be able to write
>
> (#"parallelize" *sc* (jlist-from-list '(1 2 3 4 5)))
>
> It would be helpful to know if this doesn't work, as it means there's
> something I need to learn.
>
>
> But I can't help but think that going from a list to an array to a list is
> the long way 'round. Is there a better or more idiomatic way to do this?
>
>
> In this case it's not really going the long way around. #"asList" takes a
> variable number of arguments - its java method signature is (T... a). JSS
> doesn't yet know about varargs. The way java implements varags is to
> actually create a method that takes an *array* of the arguments, and then
> when calling the method, add code to pack the arguments into an array.
> That's what you did - pack the arguments into an array, doing what the java
> compiler would do.
> See
> https://stackoverflow.com/questions/21746663/how-does-jvm-implement-the-varargs
>
> I'm going to think about how to make varargs work as expected so you could
> use a more natural syntax
> (#"parallelize" *sc* (#"asList" 'Arrays 1 2 3 4 5)).
>
> But, as I said, the implementation of jlist-from-list should be adequate.
> If you can verify that then we can add (an optimized version of) it to abcl.
>
> More generally, I think much of the confusion is that a Lisper will enter
> into the FFI with a certain set of assumptions that don't hold. An array is
> a type of list?
>
>
> What's the basis for thinking this?
>
> No Array class? Only specific types of array classes (e.g. array of Int)?
>
>
> Not following. It would be useful for us if you to unpack how someone
> would come to these conclusions. We could  make the documentation better so
> as to try to avoid the confusion.
>
> I was hoping that this was or could be papered over in a manner similar to
> CFFI where I barely notice I'm using an external library most of the time.
>
>
> Well, that's the intent of JSS (I was the original author of JSS, BTW).
> In this case I think you are effectively arguing that we should coerce lisp
> lists and arrays passed as java arguments to a java equivalent. That's also
> something I can think about. The downside of this is that sometimes I
> *want* to pass a cons. I suppose we could provide both, making coercing be
> the default and add syntax to escape it, so
> (#"parallelize" *sc* '(1 2 3 4 5))
> and
> (#"add" jlist (the cons '(1 2 3 4 5)) if I wanted to have an element of
> jlist be a cons.
>
> There's still an issue that there are multiple implementations of java's
> List and we aren't indicating which one is desired. So we'd have to pick a
> default, like java.util.ArrayList. We'd have to document that if a
> different type of list was wanted it needs to be created explicitly, ala
> jlist-to-list. Similarly for arrays. If one writes:
> (#"myMethod" ob #(1 2 3 4 5))
> should it pass a byte array? an integer array? an array of Objects? Again
> we'd have to choose a default, presumably what jarray-from list does - The
> array type is the  java type of the first argument. In this case that would
> be java.lang.Integer. Again I suppose we could add syntax to help.
> (#"myMethod" ob (the (array byte) #(1 2 3 4 5)))
>
> Any JSS users have an opinion?
>
> Alan
>
> On Saturday, July 25, 2020, 12:35:08 PM GMT+8, Alan Ruttenberg <
> alanruttenberg at gmail.com> wrote:
>
>
> Try just using a java list.  As I understand it, that should work the same
> way.
> Since Java.util.List is abstract,  you need to choose a concrete class,
> such as ArrayList.
>
> (let ((jlist (jss::new 'arraylist)))
>   (loop for el in '(1 2 3 4 5)
>         do (#"add" jlist el))
>   (print (jss::jlist-to-list jlist))
>   jlist)
>
> The print statement is to verify that we got what was expected, and to
> demonstrate jlist-to-list.
> Alan
>
> On Fri, Jul 24, 2020 at 10:21 PM Steven Nunez <steve_nunez at yahoo.com>
> wrote:
>
> I think what parallelize
> <https://spark.apache.org/docs/latest/api/java/org/apache/spark/api/java/JavaSparkContext.html#parallelize-java.util.List->really
> needs is a java.util.list. Alessio mentioned some reasons why an automatic
> conversion is challenging; perhaps a restart is easier? I.e. search for a
> method of the given name that takes a java.util.list, and if you're giving
> it an abcl.cons, the restart asks if you want an automatic conversion.
>
> Trying such a conversion manually, it seems I need a jlist-from-list, but
> this doesn't exist in the JAVA package.  How do I get a java.util.list from
> an abcl.cons ?
>
>
>
> On Saturday, July 25, 2020, 5:20:30 AM GMT+8, Alan Ruttenberg <
> alanruttenberg at gmail.com> wrote:
>
>
> If you send a smallish example of the code that doesn't work, and a list
> of the dependencies, I can have a look. I've been dealing with some stuff
> recently that might make it easier to debug.
> You definitely can't use CopyToArray that way. You need to work with a
> java array
> (jarray-from-list '(1 2 3 4 5))
> Maybe:
> (#"parallelize" *sc* (jarray-from-list '(1 2 3 4 5)))
>
> Alan
>
> On Thu, Jul 23, 2020 at 11:03 PM Steven Nunez <steve_nunez at yahoo.com>
> wrote:
>
> OK, I'm on lines 4 and 5 of 'hello world' and ran into yet another brick
> wall. Trying to convert the following two lines into ABCL:
>
> List<Integer> data = Arrays.asList(1, 2, 3, 4, 5);JavaRDD<Integer> distData = sc.parallelize(data);
>
>
> it looks like it should be easy. Heck, I can do that in one line:
>
> (#"parallelize" *sc* '(1 2 3 4 5)) ; *sc* defined yesterday and known to
> be correct
>
> But no, it claims "no applicable method named parallelize found on
> JavaSparkContext" (but there is!). Reading through section 3.1.1 of the
> documentation, it appears that this is probably because '(1 2 3...) is a
> LispObject and not a Java object (why no automatic conversion?). Let's try
> to convert it:
>
> (#"parallelize" *sc* (#"copytoArray" '(1 2 3 4 5)))
>
> No instance method named copytoArray found for type
> org.armedbear.lisp.Cons'
>
> And the same with using an array, e.g. (#"parallelize" *sc*
> (#"copytoArray" #(1 2 3 4 5)))
>
> *Sigh*
>
> It's been a week and my intention was to have a working prototype by now
> and present ABCL as a viable alternative to use in a project. I haven't got
> past line 5 in 'hello world'. This doesn't bode well.
>
> I've been reading about ABCL for years, and it's impressive. Full MOP,
> extensible sequences, nearly 100% ANSI compliance, and the ability to
> deploy on the JVM are major achievements. However, as a not-inexperienced
> Lisp programmer, I find the barrier to entry remarkably high and the
> documentation and examples sparse and insufficient to surmount the hurdles
> I encountered.
>
> Please take these comments in the way they are intended: constructive
> feedback from someone who is a fan of the project and would love to be able
> to use it. It's nearly impossible to get Lisp introduced into enterprise
> environments, and ABCL provides a wedge into those types of projects,
> ticking the boxes on deployment and ability to work with legacy Java code.
> Perhaps it makes more sense to someone approaching Lisp from the Java side,
> but coming from the Lisp side to Java, there's a high barrier to entry. I
> know that no volunteer wants to write documentation, but more and clearer
> docs are sorely needed here. This is probably not news, but sometimes it
> helps to be reminded of the obvious.
>
> I hate giving up, so this will be a personal background project in the
> hopes that at the next opportunity things will have improved to the point
> where we can consider introducing ABCL, so if anyone has any pointers,
> generally (though I think I would have found any docs or examples (lsw2) by
> now) and explaining this problem in particular, it would be greatly
> appreciated.
>
> @easye, you mentioned your ember project. If you're going to continue with
> that, please message me. A Spark wrapper would be useful, serve as a good
> exemplar for using ABCL to wrap a large library and, with a companion
> tutorial, help others overcome the kind of obstacles I've encountered. I'd
> be happy to contribute.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20200727/b557bb23/attachment-0001.htm>