FFI in 1.1
Locked
12
12
 
|
Hi all
Do we add FFI by default in 1.1? This was the plan so. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <[hidden email]> wrote: Hi all 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. _______________________________________________ Pharo-project mailing list [hidden email] 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: [hidden email] Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <[hidden email]>
wrote: Hi all 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/4/20 Schwab,Wilhelm K <[hidden email]>
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
_______________________________________________ Pharo-project mailing list [hidden email] 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 < [hidden email] > escreveu: 2010/4/20 Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: [hidden email] Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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, [hidden email] 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 < [hidden email] > escreveu: > > > > > 2010/4/20 Schwab,Wilhelm K <[hidden email]> > > > > 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck > Sent: Monday, April 19, 2010 9:49 PM > To: [hidden email] > Subject: Re: [Pharo-project] FFI in 1.1 > > > > > > On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by csrabak
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Tuesday, April 20, 2010 2:56 PM To: [hidden email] 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 < [hidden email] > escreveu: 2010/4/20 Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck Sent: Monday, April 19, 2010 9:49 PM To: [hidden email] Subject: Re: [Pharo-project] FFI in 1.1 On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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 < [hidden email] > 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, [hidden email] 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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck > Sent: Monday, April 19, 2010 9:49 PM > To: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
2010/4/20 Mariano Martinez Peck <[hidden email]>:
> > > On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse > <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Wed, Apr 21, 2010 at 5:54 AM, Igor Stasenko <[hidden email]> wrote: 2010/4/20 Mariano Martinez Peck <[hidden email]>: 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 _______________________________________________ Pharo-project mailing list [hidden email] 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Sun, Apr 25, 2010 at 6:04 PM, Stéphane Ducasse <[hidden email]> wrote:
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 [hidden email] 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 11:13 AM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
+2 :)
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 11:47 AM To: [hidden email] 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote:
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |