VM for Athens Graphics

I'm excited about the upcoming move to Athens graphics and would like to support that effort. It seems like the base is still under heavy development and that I should use an up-to-date Pharo 3.0 to properly use it. Let me know if that is incorrect.

I was wondering for what VMs Athens is applicable. Would it automatically work on Linux? I've also been using Pharo / Squeak on the iPad. Would Athens work there or would the VM have to be changed?

The latest Pharo vms for all 3 major platforms support Athens with Cairo as backend.
It is our starting point, one day we might choose to have different backend(s), like opengl etc.

For the ipad , best would be to implement a quartz backend for athens.

As a temporary solution we could try to compile cairo library for it, but i am not expert in iOS
to say if it can be done without much fuss.
Also, since iOS is famous for banning any applications which using generated code,
that means it should be done by writing a VM plugin and then adopting new primitives to
work with Athens API.

On Tue, Oct 22, 2013 at 7:37 PM, Igor Stasenko <[hidden email]> wrote:

The latest Pharo vms for all 3 major platforms support Athens with Cairo as backend.
It is our starting point, one day we might choose to have different backend(s), like opengl etc.

Excellent. I'm mainly using Linux.

 

For the ipad , best would be to implement a quartz backend for athens.

As a temporary solution we could try to compile cairo library for it, but i am not expert in iOS
to say if it can be done without much fuss.
Also, since iOS is famous for banning any applications which using generated code,
that means it should be done by writing a VM plugin and then adopting new primitives to
work with Athens API.

While I would love to use such a thing on iOS, I'm afraid that VM making is beyond me. That said, if somebody does it, I do have a few multi-touch tools, such as a keyboard, that I'd be willing to port to it.

Increasingly, touch based machines are going to replace mouse based machines as the dominant paradigm.

If we can create a great development environment for touch, we'd have a good chance to really invent the future. Graphic processor accelerated graphics are part of that. A rewrite of the events infrastructure, both to simply the current mess and to add touch support, is part of that.

Cheers,

Jeff

--
Jochen "Jeff" Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Mouse i much more precise than fingers. I doubt it going to be replaced. I think it will stay.

On Oct 22, 2013, at 7:37 PM, Igor Stasenko <[hidden email]> wrote:

On 22 October 2013 16:09, J.F. Rick <[hidden email]> wrote:

I'm excited about the upcoming move to Athens graphics and would like to support that effort. It seems like the base is still under heavy development and that I should use an up-to-date Pharo 3.0 to properly use it. Let me know if that is incorrect.

 

The latest Pharo vms for all 3 major platforms support Athens with Cairo as backend.
It is our starting point, one day we might choose to have different backend(s), like opengl etc.

But Athens is an API so the idea is that we should be able to switch to other rendering back-end wtihout been forced to rewrite everything. 

I was wondering for what VMs Athens is applicable. Would it automatically work on Linux? I've also been using Pharo / Squeak on the iPad. Would Athens work there or would the VM have to be changed?

 

For the ipad , best would be to implement a quartz backend for athens.

As a temporary solution we could try to compile cairo library for it, but i am not expert in iOS
to say if it can be done without much fuss.
Also, since iOS is famous for banning any applications which using generated code,
that means it should be done by writing a VM plugin and then adopting new primitives to
work with Athens API.

Igor it also means that we should find a way to get nativeboost wroking on iPad (probably by generating a "DLL" from NB).

On Wed, Oct 23, 2013 at 1:32 PM, Igor Stasenko <[hidden email]> wrote:

Mouse i much more precise than fingers. I doubt it going to be replaced. I think it will stay.

"When we were an agrarian nation, all cars were trucks because that’s what you needed on the farms. But cars eventually became more prevalent as people moved to cities. PCs will be like trucks…they are still going to be around, but there is a transformation coming, and it will make some people uneasy. Is it the iPad? Who knows? Will it be next year or five years from now?" -Steve Jobs

Yes, mice will stick around but they won't be the dominant paradigm of computing. Already, tablet sales have eclipsed the sales of desktops / laptops. Fingers aren't inherently less precise. I, for instance, am very happy using an Apple trackpad rather than a mouse. Touch screens have a fat finger problem (i.e., you are often covering up what you are wanting to precisely touch), but precision in itself isn't the problem.

On Oct 23, 2013, at 1:52 , Stéphane Ducasse <[hidden email]> wrote:

On Oct 22, 2013, at 7:37 PM, Igor Stasenko <[hidden email]> wrote:

For the ipad , best would be to implement a quartz backend for athens.

As a temporary solution we could try to compile cairo library for it, but i am not expert in iOS
to say if it can be done without much fuss.
Also, since iOS is famous for banning any applications which using generated code,
that means it should be done by writing a VM plugin and then adopting new primitives to
work with Athens API.

Igor it also means that we should find a way to get nativeboost wroking on iPad (probably by generating a "DLL" from NB).

There's another reason why Igor said a plugin backend would be the easier way, if you were to use NB, you'd also first need to implement AsmJit for ARM, as well as an ARM version of the entire NB FFI machinery , which would be large efforts in and of themselves. 

Cheers,

Henry

 

Well implementing ARM-FFI is largely orthogonal to Athens.

Yes, i am happily using it for Cairo and it lets me customize /rethink things as they go

without need to touch VM. Which means much faster development process and feedback etc.

But since Athens API is settled down more or less, now it is quite possible to implement a plugin

for different backend, knowing that it won't require huge changes later.

Ok I was not aware you were thinking about that. So this is good to have this path in my radar.

Concerning ARM:

 - Damien Pollet works on ARM assembler for ASMJit.

as soon as it working, we can try doing something with it.

But in addition, what i would like to do is to move more towards platform-neutral FFI implementation,

using low-level assembler DSL which is platform neutral. There's a work started on it

as part of Mate project, but it is yet far from finished.

I would love that.

Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly

would make it a no go for iPad and friends.

I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file"

so that we do not have the "assembly generation" problem?

Am 23.10.2013 um 23:28 schrieb Igor Stasenko <[hidden email]>:

On 23 October 2013 23:13, Stéphane Ducasse <[hidden email]> wrote:

 

Well implementing ARM-FFI is largely orthogonal to Athens.

Yes, i am happily using it for Cairo and it lets me customize /rethink things as they go

without need to touch VM. Which means much faster development process and feedback etc.

But since Athens API is settled down more or less, now it is quite possible to implement a plugin

for different backend, knowing that it won't require huge changes later.

Ok I was not aware you were thinking about that. So this is good to have this path in my radar.

Yes, this is actually what we discussed recently with Esteban about possible alternatives and

low-hanging fruits :)

 

Concerning ARM:

 - Damien Pollet works on ARM assembler for ASMJit.

as soon as it working, we can try doing something with it.

But in addition, what i would like to do is to move more towards platform-neutral FFI implementation,

using low-level assembler DSL which is platform neutral. There's a work started on it

as part of Mate project, but it is yet far from finished.

I would love that.

Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly

would make it a no go for iPad and friends.

I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file"

so that we do not have the "assembly generation" problem?

that's a big question, whether such idea fits into apple technicians/politicans heads or not.

Do you think we have enough time/resources to waste on implementing such mechanism

only to discover later that Apple says 'over my dead body'?

The point is that generating code, saving it to file, and then loading that file as DLL,
is largely a hack.
You either allowed to run your own generated code or not.. because from security perspective,
the fact that you first stored it into file and then load it back doesn't changes a tiny bit.

You store the code in a file in order to rip off the code generation part from your image. That would make it comply to apples policies. Same goes for the compiler. You are also not allowed to download a library and use it in your program. I think the plot is that apps get examined before they are allowed to be in the appstore. Changing the runtime would break this certification of the binary and apple would loose control because everybody would add a clean binary to the examination process and then they would load everything else when the user opens the app for the first time. So there is some sense in this. It is just a different way of thinking that we find annoying.

Norbert

From design perspective, it is crutch, which don't really buys anything (why on earth, anyone would want to deal with files
and OS, if he could just run code which already in memory?).

Am 24.10.2013 um 12:51 schrieb Igor Stasenko <[hidden email]>:

On 24 October 2013 08:24, Norbert Hartl <[hidden email]> wrote:

Am 23.10.2013 um 23:28 schrieb Igor Stasenko <[hidden email]>:

On 23 October 2013 23:13, Stéphane Ducasse <[hidden email]> wrote:

 

Well implementing ARM-FFI is largely orthogonal to Athens.

Yes, i am happily using it for Cairo and it lets me customize /rethink things as they go

without need to touch VM. Which means much faster development process and feedback etc.

But since Athens API is settled down more or less, now it is quite possible to implement a plugin

for different backend, knowing that it won't require huge changes later.

Ok I was not aware you were thinking about that. So this is good to have this path in my radar.

Yes, this is actually what we discussed recently with Esteban about possible alternatives and

low-hanging fruits :)

 

Concerning ARM:

 - Damien Pollet works on ARM assembler for ASMJit.

as soon as it working, we can try doing something with it.

But in addition, what i would like to do is to move more towards platform-neutral FFI implementation,

using low-level assembler DSL which is platform neutral. There's a work started on it

as part of Mate project, but it is yet far from finished.

I would love that.

Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly

would make it a no go for iPad and friends.

I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file"

so that we do not have the "assembly generation" problem?

that's a big question, whether such idea fits into apple technicians/politicans heads or not.

Do you think we have enough time/resources to waste on implementing such mechanism

only to discover later that Apple says 'over my dead body'?

The point is that generating code, saving it to file, and then loading that file as DLL,
is largely a hack.
You either allowed to run your own generated code or not.. because from security perspective,
the fact that you first stored it into file and then load it back doesn't changes a tiny bit.

You store the code in a file in order to rip off the code generation part from your image. That would make it comply to apples policies. Same goes for the compiler. You are also not allowed to download a library and use it in your program. I think the plot is that apps get examined before they are allowed to be in the appstore. Changing the runtime would break this certification of the binary and apple would loose control because everybody would add a clean binary to the examination process and then they would load everything else when the user opens the app for the first time. So there is some sense in this. It is just a different way of thinking that we find annoying.

The sense is that i'm not changing NativeBoost each time i using it, so i am not "changing the runtime".

It is pure fallacy to consider code as something else than just simple data.

Sure thing, if i mutate the codebase by loading external code from random source later (and this is what we regularly do with our images)
then the contract is broken. But not in case when all my code and i'm not changing it in any way. The fact it using code generation doesn't means it will turn into something else if i don't want to.

It is all about if you have the possibility to change the runtime at runtime or not. If you put native code into a file and remove everything that might change it you have the runtime apple wants. For me this is not philosophical debate so I don’t go into details. I don’t even like coming close to defend the way apple does it. Coming from the system side I just have two hearts beating in my chest. The old one (the security/dark side) tells me you have to restrict everything to be safe. The other/new one tells me: Screw the dark side. We’ll get nowhere with this attitude, let us invent stuff instead of fear stuff. 

Norbert 

 

Norbert

From design perspective, it is crutch, which don't really buys anything (why on earth, anyone would want to deal with files
and OS, if he could just run code which already in memory?).

--
Best regards,
Igor Stasenko.