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.
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.)
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.
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.
Who's this "extempore" jerk?
Wow, that's fantastic. Why are people keeping this to themselves?
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
> 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.
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.
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
The above could be fixed like so:
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.
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.
--
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.
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.
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!
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.
Remaining issues:
--
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.
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.
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
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.
--
--
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.
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.
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]
--
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.
--
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.
--
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.
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.
If people can offer help, I would be very happy to help getting those people started.
Thanks and bye,
Simon
--
--
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.
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.
I'm going to jump in here and say that another (somewhat ridiculous, but workable!) compilation route isScala -> Javascript -> Webkit/PhoneGap/PhoneJS/Titanium
--
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.
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 =)
--
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.