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? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 22 October 2013 16:09, J.F. Rick <self@je77.com> 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. 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.
On Tue, Oct 22, 2013 at 7:37 PM, Igor Stasenko <siguctua@gmail.com> 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
On 23 October 2013 08:12, J.F. Rick <self@je77.com> wrote:
On Tue, Oct 22, 2013 at 7:37 PM, Igor Stasenko <siguctua@gmail.com> 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.
Mouse i much more precise than fingers. I doubt it going to be replaced. I think it will stay.
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.
Yes, what interesting that morphic from the very beginning supports multiple hands concept, which fits well with multitouch. Of course you need to handle things a bit different, but still it is good basement.
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Best regards, Igor Stasenko.
On Wed, Oct 23, 2013 at 1:32 PM, Igor Stasenko <siguctua@gmail.com> 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. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 23 October 2013 14:32, J.F. Rick <self@je77.com> wrote:
On Wed, Oct 23, 2013 at 1:32 PM, Igor Stasenko <siguctua@gmail.com> 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.
Mouse if not truck. Comparing touchpad and mouse, as to me is like comparing Apples(tm) and oranges. They are both human interface devices and complement to each other. Some things you can do better using mice, some using trackpad (or touchscreen). Try controlling first-person shooter game with trackpad.. good luck :) I only hoping, one day there will be even better HID's than mouse or trackpad. As of today, they both having serious shortcomings and not universal ones to let humans control computers with muscle power. -- Best regards, Igor Stasenko.
I think the future concerning user interaction is thought reading devices. They are already at consumer level being able to perform basic brain wave scans for simple interactions even providing open source SDKs and relatively low cost at 300 euros taking into consideration that they are cutting edge technology. So software that can read your thought is already here but still in its infancy. Voice recognition is also here for quite some time now and in wide use now with Siri or whatever Apple calls it and with other companies offering similar solutions. Personally I don't see other more optimal ways. Oh and by the way comparing Apples and Oranges is both possible and useful. If you cant compare apples and oranges , then you cant think. Concerning Pharo on iOS its perfectly doable, its just a matter of someone actually doing it. Many languages have ported to iOS , there is no reason for Apple to refuse Pharo to do so.  By the way Platform agnostic Assembler sounds fascinating. I was thinking about nativeboost and it looks like it gives Pharo features that C has but without giving up the pharo syntax. It really opens a new universe of potential for Pharo. On Wednesday, 23 October 2013, 22:17, Igor Stasenko <siguctua@gmail.com> wrote: On 23 October 2013 14:32, J.F. Rick <self@je77.com> wrote: On Wed, Oct 23, 2013 at 1:32 PM, Igor Stasenko <siguctua@gmail.com> 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.
 Mouse if not truck. Comparing touchpad and mouse, as to me is like comparing Apples(tm) and oranges. They are both human interface devices and complement to each other. Some things you can do better using mice, some using trackpad (or touchscreen). Try controlling first-person shooter game with trackpad.. good luck :) I only hoping, one day there will be even better HID's than mouse or trackpad. As of today, they both having serious shortcomings and not universal ones to let humans control computers with muscle power. -- Best regards, Igor Stasenko.
On Oct 22, 2013, at 7:37 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 October 2013 16:09, J.F. Rick <self@je77.com> 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 Oct 23, 2013, at 1:52 , Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 7:37 PM, Igor Stasenko <siguctua@gmail.com> 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
On 23 October 2013 16:04, Henrik Johansen <henrik.s.johansen@veloxit.no>wrote:
On Oct 23, 2013, at 1:52 , Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 7:37 PM, Igor Stasenko <siguctua@gmail.com> 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.
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. 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. Cheers,
Henry
-- Best regards, Igor Stasenko.
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? stef
On 23 October 2013 23:13, Stéphane Ducasse <stephane.ducasse@inria.fr>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. 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 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua@gmail.com>:
On 23 October 2013 23:13, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?).
On 24 October 2013 08:24, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua@gmail.com>:
On 23 October 2013 23:13, Stéphane Ducasse <stephane.ducasse@inria.fr>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.
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.
Igor this is not the point. People do not understand that code can be represented as text :) If I save assembly in XML is it XML or assembly. I think that if you have a dll whose contents does not change then it is ok. Stef
Am 24.10.2013 um 12:51 schrieb Igor Stasenko <siguctua@gmail.com>:
On 24 October 2013 08:24, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua@gmail.com>:
On 23 October 2013 23:13, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.
On 25 October 2013 10:52, Norbert Hartl <norbert@hartl.name> wrote:
Am 24.10.2013 um 12:51 schrieb Igor Stasenko <siguctua@gmail.com>:
On 24 October 2013 08:24, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua@gmail.com>:
On 23 October 2013 23:13, Stéphane Ducasse <stephane.ducasse@inria.fr>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.
Right. In any case, Apple is not the center of universe, and there's android which is much less restrictive. We need code generation for ARM CPU.. and FFI. Whether some OS does or not supports certain things is secondary to that.
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.
-- Best regards, Igor Stasenko.
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 :)
I like these ones :)
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. 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?).
On 23 October 2013 13:52, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Oct 22, 2013, at 7:37 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 October 2013 16:09, J.F. Rick <self@je77.com> 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.
Right. And Athens on Amber is best example of that:
http://m-sp.org/gsoc2013/demo/amber-athens/
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).
aha.. and digitally sign it before you can use it.. and then ask nicely
Apple to approve it :) -- Best regards, Igor Stasenko.
participants (6)
-
dimitris chloupis -
Henrik Johansen -
Igor Stasenko -
J.F. Rick -
Norbert Hartl -
Stéphane Ducasse