[Pharo-project] FFI in 1.1
Stef, One argument made against it has been (lack of) security of the resulting image. There was also discussion of providing a command line option to suppress FFI if desired, so I think I would take both suggestions: include FFI (and/or Alien[*]) and address security concerns by allowing FFI to be disabled as the VM is launched. [*] I like the idea of being able to do callbacks in Smalltalk code, but I have also seen some mention that callouts to functions are not all that slick in Alien?? Right now, Alien might as well not exist in my world, because we have not been able to run it on Linux :( So far, I do not really have an opinion on whether it is a better way to go than FFI. As it is, we have some way to go before catching up with Dolphin; whether or not Alien is part of the answer, I can't say. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, April 15, 2010 2:31 PM To: Pharo Development Subject: [Pharo-project] FFI in 1.1 Hi all Do we add FFI by default in 1.1? This was the plan so. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!! I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. FFI is an EXTERNAL package, NOT core, neither a dev tool. That's only my opinion. Cheers Mariano
This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano, FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Hi all Do we add FFI by default in 1.1? Noooooooooo!!! I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. FFI is an EXTERNAL package, NOT core, neither a dev tool. That's only my opinion. Cheers Mariano This was the plan so. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/4/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu>
Mariano,
FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external.
But is has nothing to do with what Stef asked: "Do we add FFI by* default *in 1.1?" In my opinion, it shouldn't be by default. However, this doesn't mean that we don't support FFI. And I am not saying to focus in internal or external. I just answer Stef question with my opinion. Cheers Mariano
Bill
------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Mariano Martinez Peck *Sent:* Monday, April 19, 2010 9:49 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] FFI in 1.1
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!!
I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image.
FFI is an EXTERNAL package, NOT core, neither a dev tool.
That's only my opinion.
Cheers
Mariano
This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<blatant warning> Due the way I envisage using Pharo I have stakes in these matter¹. Please read with a grain of salt. </blatant warning> I think the 'interpretation' of Stef's question is being different from person to person. The issue Wilhelm brings it seems to me more of "what priority we give to have FFI working". Putting it as part of core IMHO has more chances of having it prioritized as we think in the release of 1.1 that if we leave it as a package, because it may be still broken and 1.1 may be called ready for shipping. I also do agree that FFI is infrastructure and as such has to be seen as core, and since the ability to have Pharo more useful depends on the possibility to use a lot of code we are not able (in some case even not willing to) to rewrite in Pharo Smalltalk, I vote to have it as default and strive to have it working as soon as possible. my 0.01999... -- Cesar Rabak [1] If you're curious, I'm interested in seeing R http://www.r-project.org/ working with Pharo (at least as Martin Rubi's smallRApi for Dolphin) Em 20/04/2010 10:15, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: 2010/4/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu> Mariano, FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external. But is has nothing to do with what Stef asked: "Do we add FFI by default in 1.1?" In my opinion, it shouldn't be by default. However, this doesn't mean that we don't support FFI. And I am not saying to focus in internal or external. I just answer Stef question with my opinion. Cheers Mariano Bill From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi all Do we add FFI by default in 1.1? Noooooooooo!!! I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. FFI is an EXTERNAL package, NOT core, neither a dev tool. That's only my opinion. Cheers Mariano This was the plan so. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Now when I say FFI this is alien if alien is available. since alien deals better with callbacks apparently. Bill my plate is full :) but this is not a problem of vision. We have cool and real dreams for Pharo. Now we should be darned pragmatic. One stone at a time... but millions of time. This is why your 30 min a week for pharo makes a real difference. Back hakcing on Rapckage. Stef On Apr 20, 2010, at 9:56 PM, csrabak@bol.com.br wrote:
<blatant warning> Due the way I envisage using Pharo I have stakes in these matter¹. Please read with a grain of salt. </blatant warning>
I think the 'interpretation' of Stef's question is being different from person to person. The issue Wilhelm brings it seems to me more of "what priority we give to have FFI working".
Putting it as part of core IMHO has more chances of having it prioritized as we think in the release of 1.1 that if we leave it as a package, because it may be still broken and 1.1 may be called ready for shipping.
I also do agree that FFI is infrastructure and as such has to be seen as core, and since the ability to have Pharo more useful depends on the possibility to use a lot of code we are not able (in some case even not willing to) to rewrite in Pharo Smalltalk, I vote to have it as default and strive to have it working as soon as possible.
my 0.01999...
-- Cesar Rabak
[1] If you're curious, I'm interested in seeing R http://www.r-project.org/ working with Pharo (at least as Martin Rubi's smallRApi for Dolphin)
Em 20/04/2010 10:15, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2010/4/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu>
Mariano,
FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external.
But is has nothing to do with what Stef asked: "Do we add FFI by default in 1.1?" In my opinion, it shouldn't be by default.
However, this doesn't mean that we don't support FFI. And I am not saying to focus in internal or external. I just answer Stef question with my opinion.
Cheers
Mariano
Bill
From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!!
I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image.
FFI is an EXTERNAL package, NOT core, neither a dev tool.
That's only my opinion.
Cheers
Mariano This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
OK, I do agree the statement about vision and your pragmatism. The matter specific with infrastructure things like FFI (I think even Alien still falls in this category) it that at some point there is need to test in all platforms supported by Pharo and I don't see this fitting in the 30'/week paradigm. . . HTH -- Cesar Rabak Em 20/04/2010 17:04, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: Now when I say FFI this is alien if alien is available. since alien deals better with callbacks apparently. Bill my plate is full :) but this is not a problem of vision. We have cool and real dreams for Pharo. Now we should be darned pragmatic. One stone at a time... but millions of time. This is why your 30 min a week for pharo makes a real difference. Back hakcing on Rapckage. Stef On Apr 20, 2010, at 9:56 PM, csrabak@bol.com.br wrote:
Due the way I envisage using Pharo I have stakes in these matter¹. Please read with a grain of salt.
I think the 'interpretation' of Stef's question is being different from person to person. The issue Wilhelm brings it seems to me more of "what priority we give to have FFI working".
Putting it as part of core IMHO has more chances of having it prioritized as we think in the release of 1.1 that if we leave it as a package, because it may be still broken and 1.1 may be called ready for shipping.
I also do agree that FFI is infrastructure and as such has to be seen as core, and since the ability to have Pharo more useful depends on the possibility to use a lot of code we are not able (in some case even not willing to) to rewrite in Pharo Smalltalk, I vote to have it as default and strive to have it working as soon as possible.
my 0.01999...
-- Cesar Rabak
[1] If you're curious, I'm interested in seeing R http://www.r-project.org/ working with Pharo (at least as Martin Rubi's smallRApi for Dolphin)
Em 20/04/2010 10:15, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2010/4/20 Schwab,Wilhelm K
Mariano,
FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external.
But is has nothing to do with what Stef asked: "Do we add FFI by default in 1.1?" In my opinion, it shouldn't be by default.
However, this doesn't mean that we don't support FFI. And I am not saying to focus in internal or external. I just answer Stef question with my opinion.
Cheers
Mariano
Bill
From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!!
I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image.
FFI is an EXTERNAL package, NOT core, neither a dev tool.
That's only my opinion.
Cheers
Mariano This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cesar, Driving R from Pharo - interesting!! But I digress. I am indeed looking at internal/external debates as a statement on priorities, and I believe FFI/Alien/os-threads/callbacks[*] should be given a very high priority. Stef clearly wants the core to be simple, and I have no desire to hobble him in that effort. A compromise there would be to have FFI and friends in Pharo, not necessarily in the core. Bill [*] From what I am reading, Alien is not so good at making calls to functions. FFI has little/no sense of callbacks, and I'm not sure that either will do anything like Dolphin's overlapped calls, which allows functions to be called from separate OS threads. The latter is critical to making things that can defend themselves against code that hangs. Don't tell me that shouldn't happen :) A hang can be as simple as something that does not return as quickly as a user had hoped; it can be as functional as using OS threads to allow OpenSSL to attempt a blocking connect w/o taking down the entire image, etc. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br Sent: Tuesday, April 20, 2010 2:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 <blatant warning> Due the way I envisage using Pharo I have stakes in these matter¹. Please read with a grain of salt. </blatant warning> I think the 'interpretation' of Stef's question is being different from person to person. The issue Wilhelm brings it seems to me more of "what priority we give to have FFI working". Putting it as part of core IMHO has more chances of having it prioritized as we think in the release of 1.1 that if we leave it as a package, because it may be still broken and 1.1 may be called ready for shipping. I also do agree that FFI is infrastructure and as such has to be seen as core, and since the ability to have Pharo more useful depends on the possibility to use a lot of code we are not able (in some case even not willing to) to rewrite in Pharo Smalltalk, I vote to have it as default and strive to have it working as soon as possible. my 0.01999... -- Cesar Rabak [1] If you're curious, I'm interested in seeing R http://www.r-project.org/ working with Pharo (at least as Martin Rubi's smallRApi for Dolphin) Em 20/04/2010 10:15, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: 2010/4/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu> Mariano, FFI, use of OS threads and callbacks are *very* basic needs that we should support. IMHO, we should be focused on making them work, not on classifying what is internal or external. But is has nothing to do with what Stef asked: "Do we add FFI by default in 1.1?" In my opinion, it shouldn't be by default. However, this doesn't mean that we don't support FFI. And I am not saying to focus in internal or external. I just answer Stef question with my opinion. Cheers Mariano Bill From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi all Do we add FFI by default in 1.1? Noooooooooo!!! I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. FFI is an EXTERNAL package, NOT core, neither a dev tool. That's only my opinion. Cheers Mariano This was the plan so. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/4/20 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!!
I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image.
FFI is an EXTERNAL package, NOT core, neither a dev tool.
Frankly, its a dev tool. What else it is if not a dev tool? You have to be extremely careful, as with anything which using C or binary interfaces, but apart from it, i see nothing wrong with it. How else you can easily bind an external API to image? Writing a plugin? You could, but what the point in spending a lot of hours writing a primitives for each API function, when in the end, you still will be doing pretty same thing: using external api?
That's only my opinion.
Cheers
Mariano
This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Wed, Apr 21, 2010 at 5:54 AM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/4/20 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi all
Do we add FFI by default in 1.1?
Noooooooooo!!!
I wouldn't include neither FFI or Alien FFI in neither PharoCore or
PharoDev
image.
FFI is an EXTERNAL package, NOT core, neither a dev tool.
Frankly, its a dev tool. What else it is if not a dev tool?
Just a library, but not a dev tool from my point of view. I understand from "dev tool" a tool aimed for make the developrs life better: good browsers, autocompletion, color hightitlying, refactoring tools, etc.
You have to be extremely careful, as with anything which using C or binary interfaces, but apart from it, i see nothing wrong with it. How else you can easily bind an external API to image? Writing a plugin? You could, but what the point in spending a lot of hours writing a primitives for each API function, when in the end, you still will be doing pretty same thing: using external api?
That's only my opinion.
Cheers
Mariano
This was the plan so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Frankly, its a dev tool. What else it is if not a dev tool?
Just a library, but not a dev tool from my point of view. I understand from "dev tool" a tool aimed for make the developrs life better: good browsers, autocompletion, color hightitlying, refactoring tools, etc.
yes communication with C library. so this is just a tool too.
On Sun, Apr 25, 2010 at 6:04 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Frankly, its a dev tool. What else it is if not a dev tool?
Just a library, but not a dev tool from my point of view. I understand
from "dev tool" a tool aimed for make the developrs life better: good browsers, autocompletion, color hightitlying, refactoring tools, etc.
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear? Stef
+1 On 25 Apr 2010, at 12:12, Stéphane Ducasse wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
+1 I would even vote for a nice Java integration if one would be available :). Cheers, Doru On 25 Apr 2010, at 18:17, Alexandre Bergel wrote:
+1
On 25 Apr 2010, at 12:12, Stéphane Ducasse wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."
On Apr 25, 2010, at 6:30 PM, Tudor Girba wrote:
+1
I would even vote for a nice Java integration if one would be available :).
I hope that johan will provide Javaconnect but this one will be a real external tool :)
Cheers, Doru
On 25 Apr 2010, at 18:17, Alexandre Bergel wrote:
+1
On 25 Apr 2010, at 12:12, Stéphane Ducasse wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+2 :) -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 11:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 On Apr 25, 2010, at 6:30 PM, Tudor Girba wrote:
+1
I would even vote for a nice Java integration if one would be available :).
I hope that johan will provide Javaconnect but this one will be a real external tool :)
Cheers, Doru
On 25 Apr 2010, at 18:17, Alexandre Bergel wrote:
+1
On 25 Apr 2010, at 12:12, Stéphane Ducasse wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, You are clear, and (IMHO) correct. We need good ability to call out (FWIW, Alien's ability here has been questioned, fairly or not??), good callbacks (FFI is seriously weak here), and at least some ability to make calls on separate OS threads to protect the image from being locked by something that does not return - we are currently helpless on the latter point. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 11:13 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear? Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way,
SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion. In summary, should I add FFI when I start to build PharoDev 1.1 ? Cheers Mariano Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us. Stef On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us. Stef On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote:
Stef,
I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien.
there are no such alien maintainers. There are us.
Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us.
Stef
On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 26 April 2010 08:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote:
Stef,
I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. Â If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien.
there are no such alien maintainers. There are us.
Innndeeeddd :) Besides, i plan to support callbacks in NativeBoost, so, you'll be able to handle callback without entering the interpreter & language-side (as well as entering - at your will ;). Handling a callbacks natively is waaay much faster than go all the way through calling interpret(), especially, when you need to do something very simple, like count bunnies :) So, Alien could use a NativeBoost as extension to do things faster, smoother & nicer :)
Also, whatever we include should work on windows, mac and Linux. Â Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. Â That would not be good for a supported platform.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us.
Stef
On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, Â SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor, Looks cool, but I really would like to know the exact difference to Exupery? For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure. Check out the Exupery documentation: <http://goran.krampe.se/exuperyDesign.pdf>. Some more questions about NativeBoost: - How do I send a message? - How do I evaluate a block passed as argument? - How do I access the VM state? Lukas On 26 April 2010 09:38, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2010 08:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote:
Stef,
I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. Â If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien.
there are no such alien maintainers. There are us.
Innndeeeddd :)
Besides, i plan to support callbacks in NativeBoost, so, you'll be able to handle callback without entering the interpreter & language-side (as well as entering - at your will ;). Handling a callbacks natively is waaay much faster than go all the way through calling interpret(), especially, when you need to do something very simple, like count bunnies :) So, Alien could use a NativeBoost as extension to do things faster, smoother & nicer :)
Also, whatever we include should work on windows, mac and Linux. Â Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. Â That would not be good for a supported platform.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us.
Stef
On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, Â SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
On 26 April 2010 10:57, Lukas Renggli <renggli@gmail.com> wrote:
Igor,
Looks cool, but I really would like to know the exact difference to Exupery?
For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure.
You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :)
Check out the Exupery documentation: <http://goran.krampe.se/exuperyDesign.pdf>.
Thanks, i read it before. I know many things about Exupery. I even contributed to Exupery codebase once upon a time.
Some more questions about NativeBoost:
- How do I send a message?
You don't. Think of a native code as a primitive.
- How do I evaluate a block passed as argument?
Same as above.
- How do I access the VM state?
Through interpreterProxy functions. In same way as any plugin does. Exupery having a good extension (which i contributed to it btw), which allows you to retrieve any VM symbol address, so then you can call any VM function or access any of its global state directly. But currently i'm trying to stay away from changing VM, because i want my plugin to work on usual VMs.
Lukas
On 26 April 2010 09:38, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2010 08:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote:
Stef,
I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. Â If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien.
there are no such alien maintainers. There are us.
Innndeeeddd :)
Besides, i plan to support callbacks in NativeBoost, so, you'll be able to handle callback without entering the interpreter & language-side (as well as entering - at your will ;). Handling a callbacks natively is waaay much faster than go all the way through calling interpret(), especially, when you need to do something very simple, like count bunnies :) So, Alien could use a NativeBoost as extension to do things faster, smoother & nicer :)
Also, whatever we include should work on windows, mac and Linux. Â Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. Â That would not be good for a supported platform.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1
Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us.
Stef
On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote:
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes communication with C library. so this is just a tool too.
Exactly. It is a tool. Not a dev tool in my opinion.In such way, Â SqueakDBX is also a tool. A tool to persist in a relational database.
Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. This is why having FFI in pharo-dev is important. We should be able to call mac native menu. Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. Am I clear?
Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. Anyway...forget this little discussion.
In summary, should I add FFI when I start to build PharoDev 1.1 ?
Cheers
Mariano
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote:
On 26 April 2010 10:57, Lukas Renggli <renggli@gmail.com> wrote:
Igor,
Looks cool, but I really would like to know the exact difference to Exupery?
For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure.
You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :)
It sounds like NativeBoost is rather similar to Exupery's lower levels. Exupery can replace individual methods with native code. Exupery's design supports the easy removal of all native code which is necessary when saving the image if it might be loaded on a platform or by a VM which can not run x86 machine code. The VM hooks are rather small and the code generator is reasonably small and simple. Exploring multiple approaches may be more valuable than saving a small amount of duplicate effort. Bryce
On 28 April 2010 00:14, Bryce Kampjes <bryce@kampjes.demon.co.uk> wrote:
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote:
On 26 April 2010 10:57, Lukas Renggli <renggli@gmail.com> wrote:
Igor,
Looks cool, but I really would like to know the exact difference to Exupery?
For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure.
You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :)
It sounds like NativeBoost is rather similar to Exupery's lower levels. Exupery can replace individual methods with native code.
Exupery's design supports the easy removal of all native code which is necessary when saving the image if it might be loaded on a platform or by a VM which can not run x86 machine code.
NativeBoost does it a bit differently. Each piece of native code having a special marker - platform id, which is checked before entering native code. If native code platform id matching the platform id of currently running VM, then native code is allowed to run, and if not, then primitive are just failing, refusing to run it. In this way, a native code can be saved in image, but having no chances to run on a wrong target platform.
The VM hooks are rather small and the code generator is reasonably small and simple. Exploring multiple approaches may be more valuable than saving a small amount of duplicate effort.
Bryce
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor, I was wondering whether you or somebody else have a real example where NativeBoost boosts performance. For instance in an often used library class... Cheers, Adrian On Apr 27, 2010, at 23:26 , Igor Stasenko wrote:
On 28 April 2010 00:14, Bryce Kampjes <bryce@kampjes.demon.co.uk> wrote:
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote:
On 26 April 2010 10:57, Lukas Renggli <renggli@gmail.com> wrote:
Igor,
Looks cool, but I really would like to know the exact difference to Exupery?
For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure.
You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :)
It sounds like NativeBoost is rather similar to Exupery's lower levels. Exupery can replace individual methods with native code.
Exupery's design supports the easy removal of all native code which is necessary when saving the image if it might be loaded on a platform or by a VM which can not run x86 machine code.
NativeBoost does it a bit differently. Each piece of native code having a special marker - platform id, which is checked before entering native code. If native code platform id matching the platform id of currently running VM, then native code is allowed to run, and if not, then primitive are just failing, refusing to run it. In this way, a native code can be saved in image, but having no chances to run on a wrong target platform.
The VM hooks are rather small and the code generator is reasonably small and simple. Exploring multiple approaches may be more valuable than saving a small amount of duplicate effort.
Bryce
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28 April 2010 10:24, Adrian Lienhard <adi@netstyle.ch> wrote:
Igor, I was wondering whether you or somebody else have a real example where NativeBoost boosts performance. For instance in an often used library class...
It depends. I provided comparisons before. But if you have any real-world example in mind, i will happily implement it and give you the numbers. Apparently there is nothing else, which can run faster than native code. I'm giving you control to implement own primitives using native code. As for FFI interface you will have a full control on how to coerce types between C and Smalltalk worlds and so, it will run as fast as you made it. :) For example, here the FFI plugin code which coercing a smalltalk object to integer value for pushing it on stack: ffiIntegerValueOf: oop "Support for generic callout. Return an integer value that is coerced as C would do." | oopClass | self inline: true. (interpreterProxy isIntegerObject: oop) ifTrue:[^interpreterProxy integerValueOf: oop]. oop == interpreterProxy nilObject ifTrue:[^0]. "@@: should we really allow this????" oop == interpreterProxy falseObject ifTrue:[^0]. oop == interpreterProxy trueObject ifTrue:[^1]. oopClass := interpreterProxy fetchClassOf: oop. oopClass == interpreterProxy classFloat ifTrue:[^(interpreterProxy floatValueOf: oop) asInteger]. oopClass == interpreterProxy classCharacter ifTrue:[^interpreterProxy fetchInteger: 0 ofObject: oop]. oopClass == interpreterProxy classLargePositiveInteger ifTrue:[^interpreterProxy positive32BitValueOf: oop]. ^interpreterProxy signed32BitValueOf: oop "<- will fail if not integer". See , how generic it is? It tries to accept every possible combination which could be translated to native integer value. Now, suppose, that you know _exactly_ that your function will be called only with smallintegers as arguments, and want to fail primitive if it get called with wrong argument. This is what you can do with NativeBoost, but you can't with FFI, because it is C code, compiled and made in stone.
Cheers, Adrian
-- Best regards, Igor Stasenko AKA sig.
participants (10)
-
Adrian Lienhard -
Alexandre Bergel -
Bryce Kampjes -
csrabak＠bol.com.br -
Igor Stasenko -
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse -
Tudor Girba