Scala for IOS please.

[JamesJ]

If anyone has the requisite skills, I would really like to support the development of some sort of Scala to IOS compile chain.  If there were a kickstarter project or similar I would be willing to commit several hundred dollars today to someone who has the skills and a good plan to do this.

I keeps noticing more projects where Scala is being compiled for non JVM environments.

It would be great to see a lightweight way to do Scala development on Apple Tablets and phones.  I.e. forget about the Java myth of write once run everywhere, and only provide the thinnest possible wraper over the underlying OS.

Android abandoned the write once run anywhere to great benefit.  I mean, look, Java is just now working on supporting Multi-touch.  I would much rather have to port apps with common controllers in a common language to different semi-native interfaces, than try to use one common environment that takes years to adopt the common capabilities in the underlying OSes.  I love Scala.  I use it on Android.  I need support for Apple devices.

Just think of all of those Java developers that would like to do apps on IOS.  Oracle is dragging their feet.  This would be a Killer Scala ecosystem win.  A short bridge from Java skills to IOS that avoids Java, and their restrictions entirely.

I know that it is probably very unlikely, but it doesn't hurt to ask.

James

[Rex Kerr]

Why would Apple not be super-grumpy (in a technical/legal sense) about this?

It's not like there are any huge technical barriers to putting a JVM on iOS now, or any substantive difference between having a JVM on an iOS device vs. having a browser with JavaScript on an iOS device, except that Apple is grumpy.

You might, however, be interested in Xamarin.  Not Scala, obviously, but it's not Objective C either and it is possibly crossplatformy.  Not exactly write once run everywhere, but at least there's Mono for Android.

  --Rex

[Haoyi Li]

Didn't apple back off from the YOU_MUST_USE_OBJ_C thing a while ago?

Not to say that porting scala to a new platform is anything but incredibly technically difficult, or the work the Xamarin/RubyMotion guys do is anything but absolutely amazing, but at least Apple won't shut you down anymore I think.

[Rex Kerr]

They didn't back off enough to let you use a JVM (or Flash).  Oracle has sort of hacked a way around it by bundling a full JVM with every app.  This is ludicrous, but apparently works.

The amount of technical idiocy that we have to put up with because of grumpy corporations is rather depressing.  You'd think there'd be an awesome VM--one substantially better than is possible with JavaScript engines--that would run cross-platform.  But Apple won't let Oracle do it for iOS, and Oracle won't let Google do it (or, well, they tried not to with hefty legal muscle) for Android.  Microsoft isn't even trying to do it with the CLR, though they could.

  --Rex

[Haoyi Li]

I meant on the language level; previously you couldn't even write C#/Ruby/etc. applications even if they compiled to Obj-C before shipping. At least now you can, albeit with the crazy cross-compilation stuff like what xamarin/rubymotion does. Not quite the same as (actually pretty damn far away from) having a native mono/ruby/etc. runtime, but it's a (small) step forward!

[Sebastian Nozzi]

I'm new to Scala and its projects but: wasn't there an initiative to bring a LLVM back-end to Scala? That way you would not need a complete JVM to deploy on iOS devices. Needless to say, iOS deployment would be but *one* of the possibilities.

Didn't know about http://www.drdobbs.com/jvm/javaone-javafx-2-java-on-ios/231900029 , very interesting.

[Kostya Golikov]

You can give Avian a chance (it is a new JVM that said to be able to run on iOS): http://oss.readytalk.com/avian/

There is some problems with it, e.g. https://groups.google.com/forum/?fromgroups=#!topic/avian/Hugny4JcnDw
Moreover, non-jailbraked devices doesn't allow your code to be JITed

воскресенье, 13 января 2013 г., 2:45:17 UTC+4 пользователь jamesj написал:

[James Black]

It would be more work, but you could write the runtime in Objective-C and it can do the Scalar parsing.

Objective-C is nice in that it does late binding so methods can be dynamically declared.

[Sebastian Nozzi]

You mean a Scala *interpreter* ?

2013/1/14 James Black <planit...@gmail.com>:

[James Black]

Yes, it would interpret the Scala code and run it in the runtime written in Objective-C.

--

Resume & Projects: http://careers.stackoverflow.com/jamesblack

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant."
- Robert McCloskey

[Stefan Zeiger]

On 2013-01-14 12:07, James Black wrote:
> Yes, it would interpret the Scala code and run it in the runtime
> written in Objective-C.

To this day people associate "Java" with "horribly slow". We can't
possible pass up the chance of getting "Scala = horribly slow" into the
heads of a new generation of smartphone users!

[Peter Salanki]

+1

[Simon Ochsenreither]

This looks very interesting!

I'm wondering .... would it make sense to have a build machine testing Scala on Avian as soon as the worst bugs seem to be fixed?

[JamesJ]

I think that the most interesting approach is to build a straight Scala to Objective C compiler.  Apple seems to allow this approach while expressly forbidding a VM.  If Java or Scala can be compile to Javascript, why not Objective C?  (I know, just tons of work.)

[Paul Phillips]

On Mon, Jan 14, 2013 at 6:42 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I'm wondering .... would it make sense to have a build machine testing Scala on Avian as soon as the worst bugs seem to be fixed?

I also think it looks interesting, but the cart is over here and the horse is way, way over there. Do you have some evidence that scala is anywhere near functioning on avian? Show me that much, then we can talk about a "build machine", because it seems terribly unlikely. (If it IS anywhere near working, I would be all over it.)

[Simon Ochsenreither]

I also think it looks interesting, but the cart is over here and the horse is way, way over there. Do you have some evidence that scala is anywhere near functioning on avian? Show me that much, then we can talk about a "build machine", because it seems terribly unlikely. (If it IS anywhere near working, I would be all over it.)

It seems like they already successfully ran Scala, including the REPL, on Avian. Even Akka seems to be almost there, sans one bug which looks like a scalac bug.

https://groups.google.com/d/topic/avian/Hugny4JcnDw/discussion
https://groups.google.com/d/msg/avian/b_n4QbIP9jY/ArIA0uFV5J0J

[Paul Phillips]

On Mon, Jan 14, 2013 at 9:09 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

It seems like they already successfully ran Scala, including the REPL, on Avian. Even Akka seems to be almost there, sans one bug which looks like a scalac bug.

Wow, that's fantastic. Why are people keeping this to themselves? Geez, I only heard about avian for the first time in this thread. I gave in and started using twitter specifically so I'd hear about stuff like this earlier. C'mon guys, raise your feeding-info-to-paulp games! 

[Paul Phillips]

On Mon, Jan 14, 2013 at 9:09 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

It seems like they already successfully ran Scala, including the REPL, on Avian. Even Akka seems to be almost there, sans one bug which looks like a scalac bug.

Ha ha, I read about that scalac bug where he says "reported on a scala forum" and I got on my high horse to see which ingrate it was this time reporting bugs to a mailing list rather than opening a ticket so they might actually get fixed.

Who's this "extempore" jerk?

[Paul Phillips]

On Mon, Jan 14, 2013 at 9:16 AM, Paul Phillips <pa...@improving.org> wrote:

Who's this "extempore" jerk?

I stepped in on his behalf:

https://issues.scala-lang.org/browse/SI-6969

https://issues.scala-lang.org/browse/SI-6970

[Simon Ochsenreither]

Wow, that's fantastic. Why are people keeping this to themselves?

That's my impression too. This guy seems to be both very talented _and_ responsive.

Could this be the guy where one would ask “what would it take to have proper tail calls?” and get back “done!” a day later? :-)

[joel...@gmail.com]

Avian has supported both proper tail calls and first-class continuations for several years now, so no need to wait :)

Check out the "tails" and "continuations" build options at https://github.com/ReadyTalk/avian#building

I haven't tried using either of those features with Scala, but accessing them from Clojure was trivial, FWIW: https://groups.google.com/group/clojure/browse_thread/thread/5388b89d5b187e2f/c6c27d674980ccfa

[Pablo Guerrero]

I'm really happy to see that there are many people interested on this. I thought I was alone.

[Simon Ochsenreither]

Hi Joel,

Avian has supported both proper tail calls and first-class continuations for several years now, so no need to wait :)

Wow, my mind is blown... that's impressive!
 

Check out the "tails" and "continuations" build options at https://github.com/ReadyTalk/avian#building

Reading that it seems that the optimization will kick in automatically, no changes to emitted class files necessary (like the wide bytecode which was proposed a few years ago), is that correct?

The topic came up in an unrelated thread today ... how do PTCs interact with the VM's security features? Will PTCs be disabled if security boundaries are crossed in the affected stack frames?

Thanks a lot and bye,

Simon

[Joel Dice]

On Mon, 14 Jan 2013, Simon Ochsenreither wrote:

> Reading that it seems that the optimization will kick in automatically, no
> changes to emitted class files necessary (like the wide bytecode which was
> proposed a few years ago), is that correct?

That's correct -- Avian will try to optimize every tail call it finds.
It would be easy enough to apply the optimization selectively based on
e.g. the wide bytecode or a classfile attribute, if desired.

> The topic came up in an unrelated thread today ... how do PTCs interact with
> the VM's security features? Will PTCs be disabled if security boundaries are
> crossed in the affected stack frames?

Good question. The Avian VM itself and its custom classpath doesn't have
much of a security model, since the usecases it is designed for do not
involve running untrusted code (and even Sun/Oracle can't seem to get that
right anyway). When the VM is paired with the OpenJDK class library, one
might expect at least some of the security checks in that library to fail
due to elided stack frames, but, somewhat surprisingly, I've yet to run
into that in practice.

Personally, I think it's bad design to make security decisions by peeking
at the stack to find out who's calling, but the VM could be modified to
disable PTCs across classes loaded by classloaders in different protection
domains if needed.

[Simon Ochsenreither]

> Reading that it seems that the optimization will kick in automatically, no
> changes to emitted class files necessary (like the wide bytecode which was
> proposed a few years ago), is that correct?

That's correct -- Avian will try to optimize every tail call it finds.
It would be easy enough to apply the optimization selectively based on
e.g. the wide bytecode or a classfile attribute, if desired.

Ok cool. Are there any limitations to be aware of? Does something like A-calls-B-and-B-calls-A work (I don't recall what this is called anymore)?

 

> The topic came up in an unrelated thread today ... how do PTCs interact with
> the VM's security features? Will PTCs be disabled if security boundaries are
> crossed in the affected stack frames?

Good question.  The Avian VM itself and its custom classpath doesn't have
much of a security model, since the usecases it is designed for do not
involve running untrusted code (and even Sun/Oracle can't seem to get that
right anyway).  When the VM is paired with the OpenJDK class library, one
might expect at least some of the security checks in that library to fail
due to elided stack frames, but, somewhat surprisingly, I've yet to run
into that in practice.

Personally, I think it's bad design to make security decisions by peeking
at the stack to find out who's calling, but the VM could be modified to
disable PTCs across classes loaded by classloaders in different protection
domains if needed.

Ok, thanks. This decision sounds pretty sane to me. I guess the amount of people who want to run applets with Avian is _very_ limited anyway. :-)

Thanks and bye,

Simon

PS: Do you have any opinions/plans regarding structs/value types on your VM?

[Joel Dice]

On Mon, 14 Jan 2013, Simon Ochsenreither wrote:

>

> > Reading that it seems that the optimization will kick in
> automatically, no
> > changes to emitted class files necessary (like the wide
> bytecode which was
> > proposed a few years ago), is that correct?
>
> That's correct -- Avian will try to optimize every tail call it
> finds.
> It would be easy enough to apply the optimization selectively
> based on
> e.g. the wide bytecode or a classfile attribute, if desired.
>
>
> Ok cool. Are there any limitations to be aware of? Does something like
> A-calls-B-and-B-calls-A work (I don't recall what this is called anymore)?

No, there aren't any limitations I can think of, and yes, mutually
recursive tail calls of any degree will work. The caller's stack frame is
simply replaced by the callee's, so A-calls-B-calls-C-calls-D...calls-A
will only require one frame at a time regardless of the "depth" of
recursion, assuming they're all tail calls. Even really "deep" tail call
chains with no repetition (e.g. 10 million functions, each of which tail
calls the next) will not require more than one stack frame and thus cannot
overflow the stack.

> PS: Do you have any opinions/plans regarding structs/value types on your VM?

Do you mean types such that an instance can be embedded directly (i.e. not
via reference) inside an array, object, or other struct and also be
referenced independently of the thing it is contained in? If so, it
raises some interesting questions regarding garbage collection (e.g. is an
object considered reachable if there are no references to it directly, but
there is at least one reference to a struct it contains?). I have no
current plans to implement such a thing, but I'd be happy to discuss it if
there's interest.

[Rex Kerr]

Structs would be pass-by-value only.  They could be returned on the stack, stuck into an object, but you would never have a reference to one, only copies.  There could be some relatively small maximum size also (64 bytes or something would probably do it).

This allows things like full-performance complex numbers, rationals, vectors, small tuples (e.g. an object-integer pair), and so on, without the overhead of boxing.  It's then the job of whichever compiler uses these features to make this appear comfortably to be an object.  Scala already does this, except it can only wrap single items (so you can wrap a Long to appear to be an object with two Ints, for example) because of the limitations of the Sun/Oracle JVM.

I have no idea how to make this compatible with JVM bytecode, however.  And even less of an idea about how one could retain Java interoperability.

  --Rex

 

[Joel Dice]

On Mon, 14 Jan 2013, Rex Kerr wrote:

>
>
>
> On Mon, Jan 14, 2013 at 4:40 PM, Joel Dice <joel...@gmail.com> wrote:
> On Mon, 14 Jan 2013, Simon Ochsenreither wrote:
>
>
>
> PS: Do you have any opinions/plans regarding structs/value
> types on your VM?
>
>
> Do you mean types such that an instance can be embedded directly (i.e.
> not via reference) inside an array, object, or other struct and also
> be referenced independently of the thing it is contained in? �If so,
> it raises some interesting questions regarding garbage collection
> (e.g. is an object considered reachable if there are no references to
> it directly, but there is at least one reference to a struct it
> contains?).
>
>
> Structs would be pass-by-value only.� They could be returned on the stack,
> stuck into an object, but you would never have a reference to one, only
> copies.� There could be some relatively small maximum size also (64 bytes or
> something would probably do it).
>
> This allows things like full-performance complex numbers, rationals,
> vectors, small tuples (e.g. an object-integer pair), and so on, without the
> overhead of boxing.� It's then the job of whichever compiler uses these
> features to make this appear comfortably to be an object.� Scala already
> does this, except it can only wrap single items (so you can wrap a Long to
> appear to be an object with two Ints, for example) because of the
> limitations of the Sun/Oracle JVM.

Thanks for the clarification. If that's all you need, I don't see why you
can't do it all in the Scala->bytecode compiler. Let the programmer treat
the struct as an single unit, but generate bytecode that marshals the
fields one-by-one. Say you're modeling a rational as two ints: the Scala
programmer sees a function that takes a single rational parameter, but
it's really a function that takes two ints: one for the numerator and one
for the denominator. Likewise, each field is stored separately in a given
object; only the compiler knows that they're related. No need for boxing;
you just need to make sure any Java code that interoperates is aware of
the convention.

The one place this breaks down is in arrays; in that case you'd have to
tolerate an extra level of indirection and package the fields in an
object (unless you're lucky enough that all the fields are of the same
type or can be easily converted to/from a given primitive type). Is that
what you're concerned about, or is there something else I'm missing?

[Jesper Nordenberg]

Yes, I'm also pleased to see that Avian gets some interest in the Scala
community. It seems to be the most viable alternative to run Scala apps
in iOS ATM. Not that I'm an Apple fanboy, but making your app available
to a huge user base can't hurt.

/Jesper Nordenberg

> <https://issues.scala-lang.org/browse/SI-6969>
> https://issues.scala-lang.org/browse/SI-6970
> <https://issues.scala-lang.org/browse/SI-6970>
>

[Rex Kerr]

No, two places.  Return values also break down.  That's really the killer in a language full of function calls and closures and such.

Arrays are bad also, however.  Object packaging is the whole thing we're trying to avoid.

(That said, it's what Scala's value classes do now--it's the best you can manage without VM support.)

  --Rex

 

[Joel Dice]

On Mon, 14 Jan 2013, Rex Kerr wrote:

> On Mon, Jan 14, 2013 at 5:48 PM, Joel Dice <joel...@gmail.com> wrote:

> The one place this breaks down is in arrays
>
>
> No, two places.� Return values also break down.� That's really the killer in
> a language full of function calls and closures and such.

Ah, yes, good point. It makes me wonder if there's some way for the VM to
recognize and optimize operations involving POD types to avoid heap
overhead and indirection in cases like this. It certainly seems doable if
the type is modelled as a final class with only final fields; referential
transparency would give the VM plenty of freedom to keep such things off
the heap.

Does Scala currently use referentially-transparent objects to box these
values? If not, could it do so without sacrificing performance on
"normal" JVMs?

[Jesper Nordenberg]

Joel Dice skrev 2013-01-15 00:39:
> Does Scala currently use referentially-transparent objects to box these
> values? If not, could it do so without sacrificing performance on
> "normal" JVMs?

Yes, this is basically the point of case classes. Only object identity
spoils the illusion.

/Jesper Nordenberg

[Simon Ochsenreither]

Hi Joel,

No, there aren't any limitations I can think of, and yes, mutually
recursive tail calls of any degree will work.  The caller's stack frame is
simply replaced by the callee's, so A-calls-B-calls-C-calls-D...calls-A
will only require one frame at a time regardless of the "depth" of
recursion, assuming they're all tail calls.  Even really "deep" tail call
chains with no repetition (e.g. 10 million functions, each of which tail
calls the next) will not require more than one stack frame and thus cannot
overflow the stack.

Wow, very nice!

> PS: Do you have any opinions/plans regarding structs/value types on your VM?

Do you mean types such that an instance can be embedded directly (i.e. not
via reference) inside an array, object, or other struct and also be
referenced independently of the thing it is contained in?  If so, it
raises some interesting questions regarding garbage collection (e.g. is an
object considered reachable if there are no references to it directly, but
there is at least one reference to a struct it contains?).  I have no
current plans to implement such a thing, but I'd be happy to discuss it if
there's interest.

I think Rex managed to explain everything already, so let me just add this from my POV:
Scala's value classes are pushing against pretty much every boundary the JVM has and I think it reached the state where it is hitting the hard limits of what is possible on the JVM (and the dropped array support and the current limitation to one field per value class are symptoms of it).

I can only speak for me, but my impression is that tons of people would be interested in exploring what would be possible with just a little bit more help from the VM.
(Maybe Erik can comment? He's doing a lot of math-related things and has probably a lot of experience with all the issues related to value classes, unboxed representations, specialization, etc.)

From a high-level view, the two issues seem to be
- returning multiple values from a method
- how to handle arrays

Concerning the first one, I'm not really sure if there is an option which doesn't involve hacking scalac's backend (and special-casing Scala's TupleX classes in the VM doesn't look that great either...). (But maybe someone steps up and does it if he knows which changes are necessary.) As far as I have read, Avian passes function arguments on the stack already, but I guess you know a lot better whether making that accessible to bytecode is a huge amount of work or not. :-)

Regarding the second one, this looks a lot like a very limited form of specialization, in which the JVM allows further, user-defined element types for arrays in addition to the existing ones for reference and primitive types and generates a new template on demand (e. g. during class-loading or right ahead of the first actual usage).

My experience in VM technology is very limited but if there is something to test, I'd be more than willing to help.

By the way, there are currently two proposals related to this topic floating around, which might be interesting. One from Oracle's John Rose¹ and one from IBM².

(Imho, especially Oracle's proposals is pretty much underwhelming, because it is pretty similar to what Scala has to do to hack around the JVM's limitations instead of being a sane proposal to actually fix the limitations in a principled way (as one might have hoped from the leading vendor and specification lead of Java).
IBM's proposal has at least a little bit of merit imho, because their focus is quite different and more related to off-heap and native storage of instances and straightforward serialization from/to it.)

Thanks and bye,

Simon

¹ http://openjdk.java.net/jeps/169
² http://de.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007329.html

[Simon Ochsenreither]

The NullPointerException combined with the *Reference stuff reminded me of an earlier issue I hit while testing Scala on the JamVM:

~/Entwicklung/jamvm % ./bin/jamvm -cp ../classpath/share/classpath/glibj.zip:../lib/scala-current/lib/scala-library.jar:../lib/scala-current/lib/scala-compiler.jar:../lib/scala-current/lib/scala-reflect.jar scala.tools.nsc.MainGenericRunner
Exception in thread "main" java.lang.NullPointerException
   at java.lang.ref.Reference.<init>(Reference.java:125)
   at java.lang.ref.WeakReference.<init>(WeakReference.java:77)
   at scala.ref.WeakReferenceWithWrapper.<init>(WeakReference.scala:41)
   at scala.ref.WeakReference.<init>(WeakReference.scala:21)
   at scala.ref.WeakReference.<init>(WeakReference.scala:19)
   at scala.tools.nsc.SubComponent.<init>(SubComponent.scala:47)
   at scala.tools.nsc.Global$dependencyAnalysis$.<init>(Global.scala:615)
   at scala.tools.nsc.Global.dependencyAnalysis$lzycompute(Global.scala:611)
   at scala.tools.nsc.Global.dependencyAnalysis(Global.scala:611)
   at scala.tools.nsc.Global.<init>(Global.scala:332)
   at scala.tools.nsc.interpreter.IMain$$anon$2.<init>(IMain.scala:248)
   at scala.tools.nsc.interpreter.IMain.newCompiler(IMain.scala:248)
   at scala.tools.nsc.interpreter.IMain.<init>(IMain.scala:84)
   at scala.tools.nsc.interpreter.ILoop$ILoopInterpreter.<init>(ILoop.scala:107)
   at scala.tools.nsc.interpreter.ILoop.createInterpreter(ILoop.scala:122)
   at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:668)
   at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:666)
   at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:666)
   at scala.tools.nsc.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:95)
   at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:666)
   at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:81)
   at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:94)
   at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
   at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

I never reported it, because the code didn't look suspicious and I therefore assumed that the issue was at the JamVM/Classpath side ... maybe I was wrong?

Should I
- not file a bug
- file a new bug
- add this to an existing bug?

Thanks,

Simon

[André van Delft]

I would welcome a new virtual machine (SVM?), not only with better support for value classes and tail calls, but that would require less and smaller class files and archives.

In my project I have:

10 source files, 137KB (152KB on disk)

367 class files, 1800KB (2800 KB on disk)

Packed in a jar this still is 594KB.

Op dinsdag 15 januari 2013 06:20:31 UTC+1 schreef Simon Ochsenreither het volgende:

[Dave]

Maybe you could try XMLVM?
http://xmlvm.org/android/

Op zaterdag 12 januari 2013 23:45:17 UTC+1 schreef jamesj het volgende:

If anyone has the requisite skills, I would really like to support the development of some sort of Scala to IOS compile chain.  If there were a kickstarter project or similar I would be willing to commit several hundred dollars today to someone who has the skills and a good plan to do this.

I keeps noticing more projects where Scala is being compiled for non JVM environments.

It would be great to see a lightweight way to do Scala development on Apple Tablets and phones.  I.e. forget about the Java myth of write once run everywhere, and only provide the thinnest possible wraper over the underlying OS.

Android abandoned the write once run anywhere to great benefit.  I mean, look, Java is just now working on supporting Multi-touch.  I would much rather have to port apps with common controllers in a common language to different semi-native interfaces, than try to use one common environment that takes years to adopt the common capabilities in the underlying OSes.  I love Scala.  I use it on Android.  I need support for Apple devices.

Just think of all of those Java developers that would like to do apps on IOS.  Oracle is dragging their feet.  This would be a Killer Scala ecosystem win.  A short bridge from Java skills to IOS that avoids Java, and their restrictions entirely.

I know that it is probably very unlikely, but it doesn't hurt to ask.

James

[Joel Dice]

On Tue, 15 Jan 2013, André van Delft wrote:

> I would welcome a new virtual machine (SVM?), not only with better support
> for value classes and tail calls, but that would require less and smaller
> class files and archives.
> In my project I have:
>
> 10 source files, 137KB (152KB on disk)
> 367 class files, 1800KB (2800 KB on disk)
>
> Packed in a jar this still is 594KB.

FWIW, you can build Avian with the "lzma" option, which allows the VM to
read JARs which have been compressed using LZMA. The idea is to put your
classes in a JAR using e.g. "jar c0f <jarfile> <input files>" (i.e. no
compression) and then compress the whole thing at once using LZMA. This
gives better compression for two reasons: everything is compressed at once
instead of classfile-by-classfile, and LZMA is just a lot more aggressive
than Deflate (which is the default algorithm for JAR/ZIP).

However, that doesn't address the fundamental problem, which is that the
class file format is inefficient for storing lots of little classes.
Fortunately, you don't need any special VM support to tackle that problem.
Just define your own custom file format that better matches Scala's needs,
and then write a classloader that translates from that format into the
traditional format at runtime before passing them to
ClassLoader.defineClass. Of course, the classloader itself and the
classes containing any public entry points (e.g. main) would need to
remain in the traditional format, but the bulk of your app could be stored
in the custom format.

This might also be worth a look:

http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/pack200.html

[Joel Dice]

>    atscala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:666)

>
>    atscala.tools.nsc.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader
> .scala:95)
>    at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:666)
>    at
> scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:81)
>    at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:94)
>    at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
>    at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
>
> I never reported it, because the code didn't look suspicious and I therefore
> assumed that the issue was at the JamVM/Classpath side ... maybe I was
> wrong?
>
> Should I
> - not file a bug
> - file a new bug
> - add this to an existing bug?

I can't tell from the stack trace whether it's the same bug or not, but
it's possible. The key to identifying it is to look at the generated
bytecode (e.g. with javap) and look for any place where
{Soft|Weak}Reference.get() is called and the result assumed to be
non-null. The pattern I saw with the original bug was this (in Java-ish
psuedocode):

foo = mySoftReference.get();
if (foo == null) {
mySoftReference = new SoftReference(new Foo());
}
bar = new Bar(); // could cause GC, which may clear mySoftReference
mySoftReference.get().setBar(bar); // NPE if mySoftReference was cleared

The above could be fixed like so:

foo = mySoftReference.get();
if (foo == null) {
mySoftReference = new SoftReference(foo = new Foo());
}
bar = new Bar(); // could cause GC, but mySoftReference can't be cleared
// since there's also a strong reference to its referent
foo.setBar(bar); // NPE not possible (unless setBar throws one, of
// course); we could also use
// mySoftReference.get().setBar(bar) here safely if
// we wanted, but it would be slightly less efficient

Anyway, I would just file a new bug with a note that it should be
investigated to see if it's related to SI-6969 somehow.

[Paul Phillips]

On Tue, Jan 15, 2013 at 5:37 PM, Joel Dice <joel...@gmail.com> wrote:

The above could be fixed like so:

"Was" fixed like so. https://github.com/scala/scala/pull/1902

[James Lei]

Why not Corona for iOS and Android? Both founders was ex-Adobe employers who left and start their own mobile developments that has advantage over Actionscript 3. Not just lightning fast experience, it work better than Objective-C.

[Walter Chang]

how about http://www.robovm.org/?  it compiles java bytecode down to arm or x86 machine code and it includes standard java classes which are also available on android.  since it's compiled ahead-of-time, the app it makes should run on normal iphones(not jail-broken), unlike avian which requires jail-broken iphone to run in jit mode afaik.

On Wed, Jan 16, 2013 at 7:25 PM, James Lei <james...@gmail.com> wrote:

Why not Corona for iOS and Android? Both founders was ex-Adobe employers who left and start their own mobile developments that has advantage over Actionscript 3. Not just lightning fast experience, it work better than Objective-C.

--
.......__o
.......\<,
....( )/ ( )...

[Simon Ochsenreither]

how about http://www.robovm.org/?  it compiles java bytecode down to arm or x86 machine code and it includes standard java classes which are also available on android.  since it's compiled ahead-of-time, the app it makes should run on normal iphones(not jail-broken), unlike avian which requires jail-broken iphone to run in jit mode afaik.

I think it is pretty much the same in that regard. Both run on unmodified devices with AOT, and in addition to that Avian can use the JIT on jail-broken ones.
I'm currently not sure which GC Avian uses, but RoboVM uses a conservative one, so that's a big fat minus for RoboVM currently, imho.

[Walter Chang]

i didn't know avian supports aot compilation.  i stand corrected.

--
 
 

[Joel Dice]

Avian uses a custom, precise GC. There's a bit more info here:

https://groups.google.com/group/avian/msg/f6e6c7d1659d7441

I have no idea how its performance compares to VMs based on the
Boehm-Demers-Weiser collector, though. I would hope it's faster, but I
haven't done any benchmarks to find out.

[Simon Ochsenreither]

Hi Joel,

Avian uses a custom, precise GC.  There's a bit more info here:

https://groups.google.com/group/avian/msg/f6e6c7d1659d7441

I have no idea how its performance compares to VMs based on the
Boehm-Demers-Weiser collector, though.

Cool, thanks!
 

I would hope it's faster, but I haven't done any benchmarks to find out.

Well, even if their VM were faster, performance doesn't matter if I can't be sure anymore that a perfectly valid program runs successfully. :-)

Thanks and bye,

Simon

PS: The patch for SI-6969 has been merged an hour ago: https://github.com/scala/scala/pull/1902

[Joel Dice]

On Fri, 25 Jan 2013, Simon Ochsenreither wrote:

> Hi Joel,
>

> Avian uses a custom, precise GC. ï¿œThere's a bit more info here:

>
> https://groups.google.com/group/avian/msg/f6e6c7d1659d7441
>
> I have no idea how its performance compares to VMs based on the
> Boehm-Demers-Weiser collector, though.
>
>
> Cool, thanks!

> ￜ

> I would hope it's faster, but I haven't done any benchmarks to
> find out.
>
>
> Well, even if their VM were faster, performance doesn't matter if I can't be
> sure anymore that a perfectly valid program runs successfully. :-)

Are you concerned that the BDW collector (or conservative GC in general)
is unreliable? I wouldn't be. There are various pros and cons to
conservative GC, but a properly written one will never allow objects to be
prematurely collected, and I'd say the BDW one is as mature and
reliable as they come.

The only caveat is that if you're working in a low level language like C
and do something nasty with pointers such that they're "hidden" from the
GC (e.g. xor'ing pointers together), things will break. But that would
break a precise GC as well. Anyway, it's not a concern for a high-level
language like Scala.

[Simon Ochsenreither]

Are you concerned that the BDW collector (or conservative GC in general)
is unreliable?  I wouldn't be.  There are various pros and cons to
conservative GC, but a properly written one will never allow objects to be
prematurely collected, and I'd say the BDW one is as mature and
reliable as they come.

No, I had the issue in mind that VMs with conservative GCs can run out of memory, when too many “suspicious” integers look like pointers and cannot be reclaimend.
But it wasn't that serious, just wanted to say that I prefer your approach.

[Andrew Pennebaker]

Slow is better than Unsupported. There is an incredibly unproductive lack of crossplatform mobile languages. If Scala announced unhindered Android, iOS and Windows Phone/RT support tomorrow, many developers would flock to it for that reason alone.

On Monday, January 14, 2013 7:35:26 AM UTC-5, Stefan Zeiger wrote:
> On 2013-01-14 12:07, James Black wrote:
>
> > Yes, it would interpret the Scala code and run it in the runtime
>
> > written in Objective-C.
>
>
>
> To this day people associate "Java" with "horribly slow". We can't
>
> possible pass up the chance of getting "Scala = horribly slow" into the
>
> heads of a new generation of smartphone users!

[Simon Ochsenreither]

I can report that this fix seems to have fixed the issue for Avian! (The issue with JamVM seems to be something different.)

Avian doesn't handle the test causing OOMEs nicely, but apart from that, it looks pretty nice!
https://groups.google.com/d/msg/avian/Hugny4JcnDw/6aaS2woU3joJ

I guess the next step would be to run scalac on Avian to bootstrap scala. I have looked into the Ant build script, but I haven't figured out yet how much work it would be to use Avian instead of the OpenJDK (I assume we would need a lot of symlinks to make the Avian stuff look like a valid $JAVA_HOME ...).

If anyone is interested in setting up some testing infrastructure, I can at least give hints on how to build Avian (the OpenJDK option is required for instance, because the classlib shipping with Avian lacks a lot of classes).

Bye,

Simon

[Simon Ochsenreither]

I can happily report that I seem to have boot-strapped Scala successfully while running on Avian! After I managed to force Ant/scalacfork to really use the avian executable and not the java executable, it worked without any flaw!

It seems to be approximately four times slower than HotSpot, which is imho pretty impressive:

init:
     [echo]        build time: 1 February 2013, 20:36:39
     [echo]      java version: Avian 1.7.0_09 (1.7)
     [echo]         java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC
     [echo]        javac args:
     [echo]       scalac args: -Yreify-copypaste 
     [echo] scalac quick args: -Yreify-copypaste  
     [echo]          git date: 20130129-171234
     [echo]          git hash: d499db3800
     [echo]     maven version: 2.11.0-SNAPSHOT
     [echo]      OSGi version: 2.11.0.v20130129-171234-d499db3800
     [echo] canonical version: 2.11.0-20130129-171234-d499db3800

[stopwatch] [locker.lib.timer: 4:01.447 sec]
[stopwatch] [locker.reflect.timer: 1:44.725 sec]
[stopwatch] [locker.comp.timer: 7:51.470 sec]
[stopwatch] [quick.lib.timer: 4:23.371 sec]
[stopwatch] [quick.reflect.timer: 1:52.912 sec]
[stopwatch] [quick.comp.timer: 13:34.982 sec]
[stopwatch] [quick.plugins.timer: 22.401 sec]
[stopwatch] [quick.scalacheck.timer: 30.409 sec]
[stopwatch] [quick.scalap.timer: 27.932 sec]
[stopwatch] [quick.partest.timer: 28.870 sec]

So what would be necessary now to have a build machine test Scala on Avian once in a while?

Thanks and bye!

Simon

[Simon Ochsenreither]

The test suite seems to cause some trouble, though:

test.suite:
  [partest] Compiling files that are expected to build
  [partest] testing: [...]/files/pos/t1937                                        [  OK  ]
  [partest] testing: [...]/files/pos/t1642                                        [  OK  ]
  [partest] Log file '/home/soc/Entwicklung/scala/test/files/pos/t4205-pos.log':
  [partest] Possible compiler crash during test of: /home/soc/Entwicklung/scala/test/files/pos/t4205
  [partest] java.lang.OutOfMemoryError
[1]    5094 abort (core dumped)  ../lib/apache-ant-1.8.4/bin/ant test.suite

[Joel Dice]

Might be related to this:

https://groups.google.com/group/avian/msg/3ade140adb92a6e9

I'm planning to investigate (and hopefully fix) these this weekend.

[ggi...@gmail.com]

I don't have access to any iOS device, but wondered about this for the moment I've seen this thread - has anyone tried getting Scala work on iOS the way that libgdx took?

Because libgdx, a Java game library, now officially supports iOS - and there are even 2 accepted Java games on AppStore.

See http://www.badlogicgames.com/wordpress/?p=2791 for announcement with info about how it works, and http://www.badlogicgames.com/wordpress/?p=2759 for two AppStore published Java games.

They used MonoTouch + IKVM. If it worked for them, maybe it would be a good starting point for running Scala app also? Even though it requires MonoTouch license, it isn't that expensive if one thinks seriously about development on iOS.

[Joel Dice]

On Fri, 1 Feb 2013, Simon Ochsenreither wrote:

> So what would be necessary now to have a build machine test Scala on Avian
> once in a while?

We're currently using Travis to run Avian's built-in test suite every
time a commit is pushed to master:

https://travis-ci.org/ReadyTalk/avian

I'd love to expand that to a lot more tests, and a Scala bootstrap would
be a great start.

[Paul Phillips]

On Fri, Feb 1, 2013 at 1:06 PM, Joel Dice <joel...@gmail.com> wrote:

We're currently using Travis to run Avian's built-in test suite every time a commit is pushed to master:

https://travis-ci.org/ReadyTalk/avian

I'd love to expand that to a lot more tests, and a Scala bootstrap would be a great start.

This would also be a great way to disperse the nuts and bolts of how one gets to the finish line with scala/avian. I'd like to see that finish line but I don't have time to take all the arrows.

[Simon Ochsenreither]

Short update:

• Scala can be bootstrapped on Avian without issues.
• I ran the test suite afterwards, with all, except two, tests completing successfully.

Remaining issues:

• Running the test suite is currently very slow, takes 3 to 4 DAYS.
  It seems to be a GC issue, because after a while CPU utilization is at 100% (instead of 400-800%) which suggests that it is spending almost all time in single-threaded native code.
• One test failure in test/files/run/parserJavaIdent.scala which seems to be valid, but nothing serious. (Probably something related to different Unicode categories.)
• One OutOfMemoryError caused by test/partest test/files/scalacheck/Ctrie.scala.

[Alex Kravets]

May I make a humble request of the gods on mount Typesafe to take a serious look at actively getting involved at actually getting Scala running on Avian and therefore opening up a huge new industry to Scala developers ?

It's hard to think of a lower hanging fruit to pick than this one ...

Cheers ...

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Alex Kravets       def redPill = 'Scala
[[ brutal honesty is the best policy ]]

[Rich Oliver]

Personally I would rather that some of typesafe's limited and scare resourses went in to developing for LLVM. Haskell already compiles to LLVM. Couldn't LLVM be the future? I don't know but as you can compile byte code to llvm would it not be possible to start with a hybrid compiler: part Scala => bytecode => LLVM and part Scala => LLVM.

[Simon Ochsenreither]

Personally I would rather that some of typesafe's limited and scare resourses went in to developing for LLVM. Haskell already compiles to LLVM. Couldn't LLVM be the future? I don't know but as you can compile byte code to llvm would it not be possible to start with a hybrid compiler: part Scala => bytecode => LLVM and part Scala => LLVM.

Geoff Reedy is doing some work on LLVM, not sure about the status.

About LLVM being the future?  I'd say no. Despite being called LL"VM", basic tasks of a VM like GC are a huge issue (in the sense of "not really supported") where most people working on GC'ed languages resorted to using a shadow stack when targeting the LLVM. Apart from that, the compiler is currently so slow, that JIT compilation doesn't make any sense.

[Rich Oliver]

On Sunday, February 17, 2013 6:19:24 PM UTC, Simon Ochsenreither wrote:

About LLVM being the future?  I'd say no. Despite being called LL"VM", basic tasks of a VM like GC are a huge issue (in the sense of "not really supported") where most people working on GC'ed languages resorted to using a shadow stack when targeting the LLVM. Apart from that, the compiler is currently so slow, that JIT compilation doesn't make any sense.

Well its meant to be a Low level VM as opposed to the JVM which is a high level VM. Wouldn't a garbage collector be inappropriate for this level. Surely a generic GC would tie one in too closely to a particular language structure. Clearly there would be a lot more work involved for the language creators in targeting the LLVM over the JVM. But surely the LLVM would save an enormous amount of work over writing the whole stack down to machine code, but without compromising the language in the way targetting the JVM does. It seems a huge amount of energy in Scala is spent negotiating the limitations imposed by the JVM.

[Rex Kerr]

Nearly effortless interoperability with the vast and rich set of libraries made for Java is a modest price to pay for that energy.  It is not clear that the LLVM offers anything comparable.

Avian or something like it seems the better approach for the time being.

  --Rex

[Simon Ochsenreither]

Well its meant to be a Low level VM

Ho. As far as I know even its authors decided to use LLVM as a name and not as an abbreviation anymore.
 

But surely the LLVM would save an enormous amount of work over writing the whole stack down to machine code, but without compromising the language in the way targetting the JVM does.

Not having to write the optimizer/codegen from scratch would save a lot of time, but don't underestimate the amount of work to implement a decent GC (which follows the specified JVM semantics). Not sure whether the LLVM or the JVM would lead to more compromises down the road, considering that one would have to treat the LLVM as an uncooperative environment GC-wise, afaiu.

[Pablo Guerrero]

Hi,

A key thing to have Scala running on iOS with Avian is to have a good classpath. Right now, the tests are performed against Avian with the OpenJDK classpath, which, AFAIK doesn't compile on iOS.

The alternative is to use Android's classpath, that has a better license and it's simpler but "complete". We have been talking about it at the end of this thread. https://groups.google.com/forum/?fromgroups=#!topic/avian/E9BWLPpQPGA

Cheers,
Pablo

--

[John Nilsson]

Microsoft recently had to face similar issue with the .NET platform, introducing windows phone, window 8 and the windows store and not really knowing what to do with silverlight creates a similar mess. To this end they've introduced what they call the Portable Class Library ( http://msdn.microsoft.com/en-us/library/gg597391.aspx and http://stackoverflow.com/questions/5238955/what-is-a-portable-class-library ), it could be interesting to l study for inspiration.

Basically they've give developers an option to target the intersection of API:s available for the platforms you wish to support. As an added bonus, all deprecated classes are removed too.

BR,

John

[Jonathan Merritt]

Just a little extra noise.  It seems that Oracle themselves may have plans for JavaFX on iOS:
  http://fxexperience.com/2013/02/february-open-source-update/

(Blog article by Richard Blair.)

Not forgetting that this is vaporware at the moment, I wonder: if they can bring enough of the platform across to run JavaFX, then maybe Scala could run with minimal modifications too?

I wish we could hear from someone in the Oracle / JavaFX team.  Or maybe just musings from various benevolent Scala dictators on their general feeling of the situation... :-)

Jonathan Merritt

[Pablo Guerrero]

Hi Jonathan,

In my opinion OpenJDK, let alone JavaFX, is far away from running on iOS. He is just talking about making it open source, and people magically port it to iOS. The closest thing I've found is OpenJDK on ARM (in progress):
http://www.theinquirer.net/inquirer/news/2219654/red-hat-sponsors-openjdk-arm64-port

But still, they are not talking about iOS but ARM severs.

Anyway, even if someone ports OpenJDK to iOS, and Apple accepts GPL + Classpath exception license, I don't think a fat VM will easily run on mobile devices.

In my opinion, Avian + Android classpath it's easier, doesn't have license problems, and it's lighter.

Cheers,
Pablo

[Rüdiger Klaehn]

I think that these two things (Scala on LLVM and Scala on Avian) are not even remotely comparable wrt. the required effort.

Scala on LLVM would be an entirely new development that would require man-years to get to work. And it would probably fracture the plaform.

Scala on Avian seems to mostly work just fine, so all you would need to do would be to fix the few remaining issues and automate testing so that the scala test suite can occasionally be run against avian to catch regressions.

[Joel Dice]

On Sun, 17 Feb 2013, Pablo Guerrero wrote:

> Hi,
>
> A key thing to have Scala running on iOS with Avian is to have a good
> classpath. Right now, the tests are performed against Avian with the OpenJDK
> classpath, which, AFAIK doesn't compile on iOS.

It does, actually. Possible licensing issues aside, it definitely works
from a purely technical perspective.

> The alternative is to use Android's classpath, that has a better license and
> it's simpler but "complete". We have been talking about it at the end of
> this thread.
> https://groups.google.com/forum/?fromgroups=#!topic/avian/E9BWLPpQPGA

I've made some progress on this, but the C/C++ code has been a bit more
painful to deal with than expected, even on Linux which is supposedly its
"native" environment.

[Haoyi Li]

This is slightly late, but I was playing with scala on Avian as well. Apart from the massive OpenJDK classpath (which Simon used, and basically works with everything) Avian also has its own avian-classpath which is tiny in comparison (~500kb of .class files, vs ~50mb for OpenJDK).

It turns out that this avian-classpath is almost sufficient to run basic (already-compiled) scala programs. In order for it to run a scala "hello world", I just needed to add a single class (java.math.BigDecimal, scala.Predef apparently uses it). Furthermore, I managed to get it to run a reasonably sized scala project (~2200 LOC, https://github.com/lihaoyi/SVM) with minimal fuss (needed to fill in about a dozen methods that were missing; ported them over from OpenJDK). Not bad for a standard library 1% the size of OpenJDK's.

-Haoyi

--
You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.

[Joel Dice]

On Tue, 5 Mar 2013, Haoyi Li wrote:

> This is slightly late, but I was playing with scala on Avian as well. Apart
> from the massive OpenJDK classpath (which Simon used, and basically works
> with everything) Avian also has its own avian-classpath which is tiny in
> comparison (~500kb of .class files, vs ~50mb for OpenJDK).
> It turns out that this avian-classpath is almost sufficient to run basic
> (already-compiled) scala programs. In order for it to run a scala "hello
> world", I just needed to add a single class (java.math.BigDecimal,
> scala.Predef apparently uses it). Furthermore, I managed to get it to run a
> reasonably sized scala project (~2200 LOC, https://github.com/lihaoyi/SVM)
> with minimal fuss (needed to fill in about a dozen methods that were
> missing; ported them over from OpenJDK). Not bad for a standard library 1%
> the size of OpenJDK's.

Glad to hear you had success with it. We're also making good progress
with the Android class library, FWIW:
https://groups.google.com/group/avian/browse_thread/thread/82e672939466c396.
Could be a good middle ground between Avian's library and OpenJDK's. The
biggest hurdle right now is that it depends on http://site.icu-project.org
for Unicode and localization, which is quite large by default; we're
investigating ways to shink it down.

[Simon Ochsenreither]

Glad to hear you had success with it.  We're also making good progress
with the Android class library, FWIW:
https://groups.google.com/group/avian/browse_thread/thread/82e672939466c396.
Could be a good middle ground between Avian's library and OpenJDK's.

I think if that works out and the tests run reasonably fast, it might make sense to push for having a regular (nightly or weekly) test build of Scala running on top of Avian to preserve that state and prevent regressions in the future.

[Simon Ochsenreither]

I think this is starting to look very promising ...

Avian on 1 February 2013, 20:36:39; Scala 20130129-171234 d499db3800
--------------------------------------------------------------------
[locker.lib.timer:        4:01.447 sec]
[locker.reflect.timer:    1:44.725 sec]
[locker.comp.timer:       7:51.470 sec]
[quick.lib.timer:         4:23.371 sec]
[quick.reflect.timer:     1:52.912 sec]
[quick.comp.timer:       13:34.982 sec]
[quick.plugins.timer:       22.401 sec]
[quick.scalacheck.timer:    30.409 sec]
[quick.scalap.timer:        27.932 sec]
[quick.partest.timer:       28.870 sec]


Avian on 6 March 2013, 10:06:23; Scala 20130305-124913 32f04db672
-----------------------------------------------------------------
[locker.lib.timer:        3:32.182 sec]
[locker.reflect.timer:    1:37.328 sec]
[locker.comp.timer:       5:09.978 sec]
[quick.lib.timer:         3:55.661 sec]
[quick.reflect.timer:     1:41.830 sec]
[quick.comp.timer:        5:16.012 sec]
[quick.plugins.timer:       18.946 sec]
[quick.scalacheck.timer:    26.609 sec]
[quick.scalap.timer:        25.333 sec]
[quick.partest.timer:       27.276 sec]


Hotspot 64-Bit Server VM 1.7.0_15 on 6 March 2013, 12:56:32; Scala 20130305-124913, 32f04db672
----------------------------------------------------------------------------------------------
[locker.lib.timer:        1:01.513 sec]
[locker.reflect.timer:      39.489 sec]
[locker.comp.timer:       1:19.280 sec]
[quick.lib.timer:         1:14.321 sec]
[quick.reflect.timer:       39.983 sec]
[quick.comp.timer:        1:18.367 sec]
[quick.plugins.timer:       16.413 sec]
[quick.scalacheck.timer:    18.074 sec]
[quick.scalap.timer:        18.556 sec]
[quick.partest.timer:       18.679 sec]

Bye,

Simon

[Simon Ochsenreither]

FYI:

Avian on 6 March 2013, 22:10:22; Scala GenRefactored2 -neo:o2 20130304-201648 ee412cbbdb
----------------------------------------------------------------------------------------

[locker.lib.timer:        3:31.676 sec]

[locker.reflect.timer:    1:36.132 sec]

[locker.comp.timer:       5:37.822 sec]

[quick.lib.timer:         3:53.942 sec]

[quick.reflect.timer:     1:35.241 sec]

[quick.comp.timer:        5:02.685 sec]

[quick.plugins.timer:       19.597 sec]

[quick.scalacheck.timer:    25.662 sec]

[quick.scalap.timer:        23.449 sec]

[quick.partest.timer:       25.868 sec]

[strap.lib.timer:         3:51.697 sec]
[strap.comp.timer:        5:10.582 sec]
[strap.plugins.timer:       19.937 sec]
[strap.scalap.timer:        23.512 sec]
[strap.partest.timer:       25.711 sec]

[Simon Ochsenreither]

With the latest GC fixes ...

Avian on 8 March 2013, 11:20:00; Scala 2.11.0-20130306-063604-5967a664ab
------------------------------------------------------------------------
[locker.lib.timer:        3:42.545 sec]
[locker.reflect.timer:    1:42.479 sec]
[locker.comp.timer:       5:26.200 sec]
[quick.lib.timer:         4:02.013 sec]
[quick.reflect.timer:     1:47.344 sec]
[quick.comp.timer:        5:30.512 sec]
[quick.plugins.timer:       20.017 sec]
[quick.scalacheck.timer:    28.173 sec]
[quick.scalap.timer:        26.717 sec]
[quick.partest.timer:       28.362 sec]

... compilation seems to be a little bit slower, but the test suite runs very fast now.

[Dave]

I think Oracle already has ADF Mobile for targeting Android AND iOS with the same codebase.
http://www.oracle.com/technetwork/developer-tools/adf-mobile/overview/index.html
http://www.oracle.com/ADF

Op zaterdag 12 januari 2013 23:45:17 UTC+1 schreef jamesj het volgende:

[Pablo Guerrero]

Hi Dave,

ADF isn't free software, and in many situations that can be a problem, and also you would depend on this specific framework. 

Conversely, Avian has a very permissive license, and if you don't use any fancy feature from Avian, you could have an app running on Avian, OpenJDK and Android without problems (common GUI not solved yet, AFAIK).

Cheers,

Pablo

--
You received this message because you are subscribed to a topic in the Google Groups "scala-language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-language/HW4FvHVLo8k/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to scala-languag...@googlegroups.com.

[JamesJ]

I am hopeful that someday Scala on IOS will be real, given the
comments on the thread.

Back to the start of the thread. Why not do a kickstarter or some
other similar funding to get more directed manpower on this. If
everyone that could benefit from Scala on IOS contributed...

If someone or some group (with the necessary skills and background)
puts together a believable, focused kickstarter to get Scala on IOS, I
will donate at least $100. (Sounds like Avian is the front runner so
far.)

The first accomplishment would to enable running just Scala logic
code, and no GUI support. This would be a great start for those of us
that want to leverage common platform logic from desktop to web to
mobile.

Second would be to provide a thin wrapper to the existing IOS GUI
paradigms. This is what Android got right, and what Sun/Oracle keeps
getting very very wrong. They interpret write once run anywhere in
such a delusional way so that the only thing that will run everywhere
is weak and anemic. (E.g. You still can't access a simple serial USB
without going outside the platform.)

Also, their official GUI, Swing/JavaFX has lagged years behind in
cutting edge multi-touch and gesture support. Let the OS teams
innovate, let us access the OS innovations using a common language and
runtime platform with thin veneers for each OS. Good native feeling
apps (the ones that people actually pay for) require native UIs.

Hopefully,

JamesJ

[Alex Kravets]

+1. I will donate 2 Bitcoins :-)

--

You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Joel Dice]

Hi James,

On Thu, 21 Mar 2013, JamesJ wrote:

> The first accomplishment would to enable running just Scala logic
> code, and no GUI support. This would be a great start for those of us
> that want to leverage common platform logic from desktop to web to
> mobile.

I'd like to propose a game: you provide a non-GUI Scala app and I show you
how to run it on iOS. If I can do that within a week, I get a point, and
if I can't, you get a point. First person to three points wins. No
money, no prizes, just glory.

The rules:

* The app must be publicly available (not necessarily open source, but
something I and anywone else can at least download in binary form and run
without restriction), and you must provide instructions for downloading,
building (if necessary), and running the code along with any dependencies

* it must be something I can run using a pure java command on a desktop
machine (i.e. no shell scripts). For example: "java -classpath
scala-library.jar:akka-actors.jar:foobar.jar my.app.Main"

* no GUI, unless you want to use JNI to access UIKit

* no runtime bytecode generation (because I'll be using Avian, which
can't currently handle that on iOS, although I plan to remove that
restriction in the future)

* I get one week per app, starting from the time you provide
instructions for running it on the desktop

* I must provide complete, independently-verifiable instructions
starting from a working Xcode iOS dev environment (i.e. I don't need to
explain how to set up Xcode to do traditional, Objective-C iOS
development, only what to do after that point)


I think this could be a fun way to approach the project. What do you
think?

[Patrik Andersson]

Go Joel!

--

You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.

[JamesJ]

Joel,

That would be awesome. I am interested in taking you up on that. My
current architecture has the core logic already separated from
presentation, as I have already built Swing, JavaFx and Android
clients.

I don't mind making a demo of the core logic public, however my app
won't be very exciting to the general public. It is a dynamic way to
represent product catalogs, where each product has lots of variables
with lots of corner-cases.

I can't really release official product catalog data, or the source,
but I can create a standalone demo catalog command line app, and give
you access to the source if you agree not to release it. My time is
quite short at this time, so it may take a few weeks to fit it in.

If you want something open source, we would have to just choose something else.

Let me know if you are serious and I will be happy to create something
for you to demo. (I hope you win the game.)

Thanks,

James

> ...

> I'd like to propose a game: you provide a non-GUI Scala app and I show you
> how to run it on iOS. If I can do that within a week, I get a point, and if
> I can't, you get a point. First person to three points wins. No money, no
> prizes, just glory.

> ...

[Simon Ochsenreither]

Data from today:

2013-04-03T13:30:00
Scala 2.11.0-20130402-214520-b575c1ed13
Avian 13d128c7be
----------------------------------------
 locker.library                3:46.615
 locker.reflect                1:42.958
 locker.compiler               4:21.586
  quick.library                4:09.119
  quick.reflect                1:49.665
  quick.compiler               4:31.095
  quick.repl                     36.781
  quick.scalacheck               29.148
  quick.scalap                   26.854
  quick.partest                  26.973
  quick.scaladoc                 48.124
  quick.interactive              26.240
  quick.plugins                  20.067

The numbers have changed a bit because the scala compiler has been split into smaller parts, but performance is mostly unchanged.

Remaining issues as far as I currently see it:

• /files/run/blame_eye_triple_eee.scala, an issue related to NaN
• java.nio.charset.MalformedInputException: Input length = 1, an issue related to “exotic” characters, precise cause unknown (triggered by /files/run/parserJavaIdent.scala and lots of tests in test.interactive)
• /files/jvm/t7253, the test is related to binary compatibility, although the test failure seems to be caused by issues with the test setup
• illegal hardware instruction (core dumped) in test.osgi, this is very likely a VM issue

The first and the third were discovered by recently added tests, while the second one has been known for a while.

I'm not sure about the fourth one, though.

[Simon Ochsenreither]

The first one is fixed since 8c1419fb89.

[Sebastian Nozzi]

I would also be willing to gladly donate, at least, $100.

[Simon Ochsenreither]

From a Scala perspective, I'm now two test failures away from having a completely tested and bootstrapped version of Scala on Avian.

I think the hard and annoying part is working with iOS's quirks and creating the bindings between Scala/the runtime and the Objective-C libraries. Maybe it's possible to learn some lessons from Mono and RoboVM on this topic. (Apart from that, “type providers” will be the obvious solution :-D.)

Additionally, these are the items which I think would help tremendously:

• Dedicating a Jenkins job to test Scala against Avian
  
• Making Avian an officially supported runtime for Scala
• Using ARM hardware to test Scala/Avian on ARM
  
• Testing Scala on Avian with the Dalvik standard library instead of the OpenJDK one
  
• Developing a SBT plugin which simplifies the process of creating native code
• Working on embedding more information into class files to allow better JIT compilation (value types, generic types come to mind)

If people can offer help, I would be very happy to help getting those people started.

Thanks and bye,

Simon

[Sebastian Nozzi]

Today I came across: http://www.robovm.org

Might also prove a viable approach...

2013/5/19 Simon Ochsenreither <simon.och...@gmail.com>

--

[Sebastian Nozzi]

Also see this approach (Java bytecodes => .NET => native, via Xamarin)

Announcement:

https://groups.google.com/d/topic/scala-tools/W5BbmqEGD0E/discussion

Demo:

https://github.com/samskivert/ios-scala-demo

VM/Converter:

https://github.com/samskivert/ikvm-monotouch

[Gergely Kis]

Hi,

Migeran, our Java on iOS solution now has initial Scala support as well.

I just announced it on the scala-tools list:

https://groups.google.com/forum/#!topic/scala-tools/Lg9kxjaycTs

Unlike other proposals like Xamarin or RoboVM, with Migeran you can use your usual tools like the Scala IDE in Eclipse, and debug your Scala apps right on your device.

For more details please check out our blog post:

http://blog.migeran.com/2014/01/write-ios-apps-in-scala-with-migeran.html

If you have any questions regarding Migeran and/or Scala support, I am more than happy to answer.

Best Regards,

Gergely

-- 
Gergely Kis
CEO / Migeran Ltd

Web: http://migeran.com

Pre-Order Campaign on Indiegogo: http://igg.me/at/migeran

[Haoyi Li]

I'm going to jump in here and say that another (somewhat ridiculous, but workable!) compilation route is 

Scala -> Javascript -> Webkit/PhoneGap/PhoneJS/Titanium

With ScalaJS, which has gotten remarkably more mature over recent months. In particular, it's gotten stable enough to make trivial games and non-trivial touch-based games, so there's no reason why it wouldn't work for some large-class of non-performance-critical iOS apps

--

You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.

[Patrik Andersson]

How does something like ScalaJS solve the problem of calling native frameworks? What's the point of an app if it offers nothing over a plain web site with an app:ish feel to it?

[Sebastian Nozzi]

It does not, and need not. That part is solved by whatever "JavaScript => Native" framework you would be using. Like PhoneGap/Titanium, etc.

Scala.js just makes it more pleasant to produce JavaScript, or interface with existing JavaScript.

2014/1/14 Patrik Andersson <pande...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "scala-language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-language/HW4FvHVLo8k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-languag...@googlegroups.com.

[Justin du coeur]

On Tue, Jan 14, 2014 at 4:08 AM, Haoyi Li <haoy...@gmail.com> wrote:

I'm going to jump in here and say that another (somewhat ridiculous, but workable!) compilation route is 

Scala -> Javascript -> Webkit/PhoneGap/PhoneJS/Titanium

*Blink*.  Not only is that not ridiculous, it's *really* interesting.

Take my project, for example.  It's gotten just about big enough to get into Javascript Hell, where I clearly need to switch to a better language for my UI.  I had originally been planning on CoffeeScript, but Scala.js is beginning to look awfully appealing as an alternative.  (Has anybody put together a canned process for integrating it into Play yet?)

On the other hand, I eventually need to build native apps, in order to access features like camera and geolocation.  When I first looked at this, many months ago, I sort of assumed I would use PhoneGap, but haven't looked at it much further yet.

The idea of killing both of those birds with one stone -- writing a single responsive UI in Scala.js, with PhoneGap extensions for the native parts -- is downright compelling for a one-man shop like mine.

Has anybody done any actual proofs of concept of this pathway?  I don't expect native-level efficiency, but if performance and bulk aren't horrible, I might have to take this idea really seriously...

[Haoyi Li]

AFAIK nobody done done any proof of concepts on mobile; the largest/most performance critical application that probably exists now is this one that I'm working on. The physics and geometry currently taxes even my i5 laptop, but it's quite conceivable that an app that doesn't need to do iterative numerical collision resolution at 60 frames per second would run just fine.

Nobody's integrated it into play, but there are some WIP efforts.

In the end, this is still kind of a science project, so don't jump into it unless you're prepared to be breaking new ground on a daily basis. On the other hand, I think the demos I've provided are enough to show it's plenty capable of writing complex, performant applications =)

--

[Justin du coeur]

On Tue, Jan 14, 2014 at 4:55 PM, Haoyi Li <haoy...@gmail.com> wrote:

AFAIK nobody done done any proof of concepts on mobile; the largest/most performance critical application that probably exists now is this one that I'm working on. The physics and geometry currently taxes even my i5 laptop, but it's quite conceivable that an app that doesn't need to do iterative numerical collision resolution at 60 frames per second would run just fine.

Heh.  Okay, cool.  I suspect that, so long as there's nothing pathologically wrong, it'll be fine for my purposes.  (Indeed, I suspect that jQuery itself will continue to be the main bottleneck.)

Realistically, I probably care more about wire size than I do runtime performance.  But I can play with it, and see how it does there.

Nobody's integrated it into play, but there are some WIP efforts.

Neat!  Sounds like I'm coming in just as the rubber is really hitting the road.

 

In the end, this is still kind of a science project, so don't jump into it unless you're prepared to be breaking new ground on a daily basis. On the other hand, I think the demos I've provided are enough to show it's plenty capable of writing complex, performant applications =)

Understood, and I'll have to take that seriously: I need to keep my primary focus on Querki proper (which is a monumentally ambitious project all by itself), and not get *too* distracted on side-projects.  That said, it looks like y'all have things to the point where the core functionality is getting adequately mature for my project (which is itself just barely in Alpha), and I may be able to contribute useful bindings libraries and the like.

I'll subscribe myself to the scala.js list, and take further questions over to there.  Hopefully, sometime in the next month or two I can scare up some time to start playing with it, and seeing whether it is, in fact, practical to port my project's UI over to it.  I'm hopeful that it is.  Thanks!

[Sebastian Nozzi]

Found this today:

https://github.com/ajhager/sbt-robovm

 

Cheers,

Sebastian

[Gergely Kis]

Hi,

We created a screencast aboout Migeran's initial Scala support, with on device debugging in action:

http://blog.migeran.com/2014/01/screencast-write-ios-apps-in-scala-with.html

Best Regards,

Gergely

ᐧ

--

You received this message because you are subscribed to a topic in the Google Groups "scala-language" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-language/HW4FvHVLo8k/unsubscribe.

To unsubscribe from this group and all its topics, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Gergely Kis
CEO
Migeran Ltd
Phone (UK): +44 203 322 3535
Phone (HU): +36 70 408 1723
Email: gerge...@migeran.com
Web: http://migeran.com