Re: [Pharo-project] FFI in 1.1
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 br...@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 reng...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On 28 April 2010 10:24, Adrian Lienhard a...@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: On 26 April 2010 10:57, Lukas Renggli reng...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On 28 April 2010 00:14, Bryce Kampjes br...@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 reng...@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
Re: [Pharo-project] FFI in 1.1
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@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
Re: [Pharo-project] FFI in 1.1
On 26 April 2010 08:41, Stéphane Ducasse stephane.duca...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@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
Re: [Pharo-project] FFI in 1.1
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 siguc...@gmail.com wrote: On 26 April 2010 08:41, Stéphane Ducasse stephane.duca...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@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
Re: [Pharo-project] FFI in 1.1
On 26 April 2010 10:57, Lukas Renggli reng...@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 siguc...@gmail.com wrote: On 26 April 2010 08:41, Stéphane Ducasse stephane.duca...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@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
Re: [Pharo-project] FFI in 1.1
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On Sun, Apr 25, 2010 at 6:04 PM, Stéphane Ducasse stephane.duca...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
+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
Re: [Pharo-project] FFI in 1.1
+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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Re: [Pharo-project] FFI in 1.1
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
+2 :) -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse stephane.duca...@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
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.duca...@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
Re: [Pharo-project] FFI in 1.1
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@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
Re: [Pharo-project] FFI in 1.1
On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: Hi All, 2010/4/20 John M McIntosh john...@smalltalkconsulting.com Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. Sounds good. I do not get anything but trying to learn. :) (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag in FFI call (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) well when will we get more Cog improvements in the vm? 2¢ Eliot On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ 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
Re: [Pharo-project] FFI in 1.1
On Apr 21, 2010, at 9:06 AM, Stéphane Ducasse wrote: On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: Hi All, 2010/4/20 John M McIntosh john...@smalltalkconsulting.com Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. Sounds good. I do not get anything but trying to learn. :) anything/everything hopefully :) (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag in FFI call (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) well when will we get more Cog improvements in the vm? 2¢ Eliot On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ 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
Re: [Pharo-project] FFI in 1.1
The question is what we call core. I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien are infrastructure. If you look at my answer to German on Re: [Pharo-project] Really Important message (tm) April 16 You can see that with a fast loading package mechanism then we could really introduce in Pharo-Core (= what we have now) infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but to Pharo from my point of view Mini Mini + FFI + Tools + IDE + Compiler = PharoCore Pharo + Sounds + Morphic examples + archiview = Pharo Note that the belonging of one package to group is not automatically clear. This is why metacello is key and a metacelloRepository. Steg I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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
Re: [Pharo-project] FFI in 1.1
Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p -- Cheers, Peter. On 20 apr 2010, at 08.59, Stéphane Ducasse stephane.duca...@inria.fr wrote: The question is what we call core. I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien are infrastructure. If you look at my answer to German on Re: [Pharo-project] Really Important message (tm) April 16 You can see that with a fast loading package mechanism then we could really introduce in Pharo-Core (= what we have now) infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but to Pharo from my point of view Mini Mini + FFI + Tools + IDE + Compiler = PharoCore Pharo + Sounds + Morphic examples + archiview = Pharo Note that the belonging of one package to group is not automatically clear. This is why metacello is key and a metacelloRepository. Steg I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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
Re: [Pharo-project] FFI in 1.1
Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
John M McIntosh wrote: Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Forget curl, I want to recreate the Cocoa class libs in squeak/pharo for WebKit... And then create etoy extensions that can handle them. ;-). Lawson ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On 20 apr 2010, at 09.13, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. Aha! Très très cool! :-D Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
But ok we need time for that and I do not have any right now. Stef On Apr 20, 2010, at 9:21 AM, Peter Hugosson-Miller wrote: On 20 apr 2010, at 09.13, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. Aha! Très très cool! :-D Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ 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
Re: [Pharo-project] FFI in 1.1
On Tue, Apr 20, 2010 at 9:14 AM, Lawson English lengli...@cox.net wrote: John M McIntosh wrote: Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Forget curl, I want to recreate the Cocoa class libs in squeak/pharo for WebKit... Cocoa ? So it will run only on Mac OS X ? Cheers, Laurent Laffont And then create etoy extensions that can handle them. ;-). Lawson ___ 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
Re: [Pharo-project] FFI in 1.1
laurent laffont wrote: On Tue, Apr 20, 2010 at 9:14 AM, Lawson English lengli...@cox.net mailto:lengli...@cox.net wrote: John M McIntosh wrote: Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Forget curl, I want to recreate the Cocoa class libs in squeak/pharo for WebKit... Cocoa ? So it will run only on Mac OS X ? Ah, no. Webkit was originally a class library in Objective C, which means (I hope) that the documented Cocoa classes for webkit should be a perfect template for wrapping the C-based webkit calls with squeak classes. Depends on how much has changed of course. Lawson ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@inria.frmailto:stephane.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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.frmailto: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
Re: [Pharo-project] FFI in 1.1
2010/4/20 Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto: pharo-project-boun...@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.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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
Re: [Pharo-project] FFI in 1.1
I think that the remarks of john is really important. If we would have a good C interaction then we can minimize also the dependencies on C plugin and the like. Stef On Tue, Apr 20, 2010 at 8:59 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: The question is what we call core. I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien are infrastructure. If you look at my answer to German on Re: [Pharo-project] Really Important message (tm) April 16 You can see that with a fast loading package mechanism then we could really introduce in Pharo-Core (= what we have now) infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but to Pharo from my point of view Mini Mini + FFI + Tools + IDE + Compiler = PharoCore Pharo + Sounds + Morphic examples + archiview = Pharo I know what you are thinking ;) But I even wouldn't put FFI neither in PharoCore or Pharo. If you want FFI, load it by yourself or in the metacello configuration of YOUR app. Cheers Mariano Note that the belonging of one package to group is not automatically clear. This is why metacello is key and a metacelloRepository. Steg I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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
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 marianop...@gmail.com escreveu: 2010/4/20 Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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 planso. Stef ___ Pharo-projectmailing 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
Re: [Pharo-project] FFI in 1.1
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, csra...@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 marianop...@gmail.com escreveu: 2010/4/20 Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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 planso. Stef ___ Pharo-projectmailing 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
Re: [Pharo-project] FFI in 1.1
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of csra...@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 marianop...@gmail.com escreveu: 2010/4/20 Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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 planso. Stef ___ Pharo-projectmailing 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
Re: [Pharo-project] FFI in 1.1
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.duca...@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, csra...@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 marianop...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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? Noo!!! 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 planso. Stef ___ Pharo-projectmailing 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
Re: [Pharo-project] FFI in 1.1
Hi All, 2010/4/20 John M McIntosh john...@smalltalkconsulting.com Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. I hope this approach would make it easier for people to produce plugins, since more of the gubbins http://www.thefreedictionary.com/gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle frameworkhttp://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag in FFI call (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) 2¢ Eliot On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ 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
Re: [Pharo-project] FFI in 1.1
2010/4/20 John M McIntosh john...@smalltalkconsulting.com: Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. +++100 On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ 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
Re: [Pharo-project] FFI in 1.1
2010/4/20 Mariano Martinez Peck marianop...@gmail.com: On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On Thu, Apr 15, 2010 at 9:31 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi all Do we add FFI by default in 1.1? Noo!!! 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
Re: [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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
