April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Need your help filling a FAQ

by Adrian Lienhard

Thanks for the explanation. It might make sense to contact Bryce [1] since Exupery probably has very similar mechanism to execute native methods (I think he is only irregularly reading this list). Maybe it makes sense to base Exupery on NativeBoost? Cheers, Adrian [1] Bryce Kampjes <bryce(a)kampjes.demon.co.uk> On Apr 25, 2010, at 23:14 , Igor Stasenko wrote: > On 26 April 2010 00:06, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 25 April 2010 23:45, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Hi Igor, >>> >>> One question I have is how your work compares to Exupery? >>> >> >> Well, i missing the good Exupery description , on squeak source it says: >> A bytecode compiler for Squeak, still an alpha project. It doesn't yet >> do anything useful but it can compile most bytecodes. >> Or from wiki page: >> Exupery is a compiler written in Smalltalk that compiles bytecodes to >> machine code. >> >> So, as you can see, an Exupery aims mainly towards turning a bytecode >> into a native code, i.e. towards implementing a JIT. >> It is important to understand that NativeBoost project having a bit >> orthogonal (or more complementary) aim - to allow you to run an >> arbitrary native code and speak directly to hardware, OS etc. >> > > Ohh.. i guess you asked about Moebius project. Sorry. > > Moebius is much more ambitious project. It is a smalltalk environment > , fully implemented in itself, i.e. > which requires no VM and minimal glue code to run on target platform. > > While Exupery, is still using a 'VM' concept which interpreting the > methods, while additionally providing facilities to optimize the > system speed by jitting some methods. > In moebius, all methods are initially contain a native code. There is > no interpreter. Sure it can be added later (as for any other language > interpreter btw), but that will not change the fact that system can > sustain itself and run without a need of having VM. > >> >> >>> Adrian >>> >>> On Apr 25, 2010, at 22:21 , Igor Stasenko wrote: >>> >>>> On 25 April 2010 23:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>> >>>>>> (a)(Smalltalk parser) -> >>>>> >>>>> could you plug the IRBuilder >>>> >>>> yes i can! The Moebius parser designed by taking in mind, that it can >>>> be used as a backend >>>> for any kind of encoding. It recognizing a smalltalk syntax and >>>> semantic elements and then passing the messages to encoder. >>>> And encoder can be anything. It can encode the parsed data into any >>>> kind of AST , its just needs to conform with parser's protocol, >>>> but can use arbitrary data structures for building the method's AST. >>>> Parser don't have _any_ assumptions, into what form an encoder >>>> translating the parsed data. >>>> >>>> So, for instance, i can implement a syntax highlighting encoder, based >>>> on this parser, without a need of having separate parser targeted only >>>> for syntax highlighting (like SHParserST80) >>>> >>>>> >>>>>> (b)(Native intermediate instructions >>>>>> generator (compiler)) -> (c)(Native code translator) >>>>>> -> (d)(AsmJit) >>>>>> >>>>>> I having a, b and d , but c is still not complete. >>>>>> And sure thing, one can use it for own purposes , since Moebius >>>>>> implemented purely in smalltalk, >>>>>> and works in Squeak/Pharo, so potentially it can be retargeted to anything else. >>>>>> >>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 26, 2010

Re: [Pharo-project] FFI in 1.1

by Lukas Renggli

Igor, Looks cool, but I really would like to know the exact difference to Exupery? For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure. Check out the Exupery documentation: <http://goran.krampe.se/exuperyDesign.pdf>. Some more questions about NativeBoost: - How do I send a message? - How do I evaluate a block passed as argument? - How do I access the VM state? Lukas On 26 April 2010 09:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 April 2010 08:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. Â If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. >> >> there are no such alien maintainers. There are us. >>> > Innndeeeddd :) > > Besides, i plan to support callbacks in NativeBoost, > so, you'll be able to handle callback without entering the interpreter > & language-side (as well as entering - at your will ;). > Handling a callbacks natively is waaay much faster than go all the way > through calling interpret(), > especially, when you need to do something very simple, like count bunnies :) > So, Alien could use a NativeBoost as extension to do things faster, > smoother & nicer :) > >>> Also, whatever we include should work on windows, mac and Linux. Â Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. Â That would not be good for a supported platform. >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >>> Sent: Sunday, April 25, 2010 3:05 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI in 1.1 >>> >>> Probably. >>> There were some discussions that alien will be integrated / working also for the windows vm. >>> So we will see which one I will let people with more experience telling that to us. >>> >>> Stef >>> >>> On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: >>> >>>> >>>> >>>> On Sun, Apr 25, 2010 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch

April 26, 2010

Re: [Pharo-project] How to copy some nice UI bits from Squeak4.1 (e.g. get rid of the fat buttons in OB)

by Lukas Renggli

Hi Tim, > "Whats with the ugly buttons in the browser"? - this is in reference to the browse|hierarchy|variables... buttons in OB. Are you sure that you use the latest OB code, because I recently made the buttons smaller? > I do know if you set the individual buttons to a #rigid style they shrink (but are too small) - so its something to do with setting the height of the container. Ok, I see. There are some hardcoded heights. I fixed this in OB-Morphic-lr.121. Depending on the theme you use this reduces the heights of the buttons a few pixels. Name: OB-Morphic-lr.121 Author: lr Time: 26 April 2010, 9:45:15 am UUID: 17704c53-3b7f-4605-9917-48ad4cecf448 Ancestors: OB-Morphic-lr.120 - let the theme decide the height of buttons Name: OB-Tests-Morphic-lr.27 Author: lr Time: 26 April 2010, 9:45:42 am UUID: dca1b619-088c-4e4c-85a1-f10a0b5e5f05 Ancestors: OB-Tests-Morphic-lr.26 - let the theme decide the height of buttons > I also wonder if its time to stop stretching buttons across the width of the browser - on a 27" iMac it looks strange when you zoom a window and get huge buttons. Whats wrong with left aligning the buttons and maybe having them all the same size? I think that looks worse. You can disable the "optionalButtonPane" in the preferences. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 26, 2010

Re: [Pharo-project] FFI in 1.1

by Igor Stasenko

On 26 April 2010 08:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. Â If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. > > there are no such alien maintainers. There are us. >> Innndeeeddd :) Besides, i plan to support callbacks in NativeBoost, so, you'll be able to handle callback without entering the interpreter & language-side (as well as entering - at your will ;). Handling a callbacks natively is waaay much faster than go all the way through calling interpret(), especially, when you need to do something very simple, like count bunnies :) So, Alien could use a NativeBoost as extension to do things faster, smoother & nicer :) >> Also, whatever we include should work on windows, mac and Linux. Â Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. Â That would not be good for a supported platform. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Sunday, April 25, 2010 3:05 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI in 1.1 >> >> Probably. >> There were some discussions that alien will be integrated / working also for the windows vm. >> So we will see which one I will let people with more experience telling that to us. >> >> Stef >> >> On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Sun, Apr 25, 2010 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 26, 2010

[Pharo-project] How to copy some nice UI bits from Squeak4.1 (e.g. get rid of the fat buttons in OB)

by Tim Mackinnon

Guys - in coming back to Smalltalk - the energy of Pharo and the improved look was something that really attracted me however as I keep finding moments to play with it, and I show other people what has been built - one of the big comments from newcomers is: "Whats with the ugly buttons in the browser"? - this is in reference to the browse|hierarchy|variables... buttons in OB. I just happened to try a new Squeak 4.1 image on the weekend, and I noticed that their buttons are much nicer - they are smaller and neater than in Pharo. I had a look to see where they are created in Pharo- I think its OBFixedButtonPanel but I am not familiar enough with these internals to know how to fix it. I do know if you set the individual buttons to a #rigid style they shrink (but are too small) - so its something to do with setting the height of the container. I also wonder if its time to stop stretching buttons across the width of the browser - on a 27" iMac it looks strange when you zoom a window and get huge buttons. Whats wrong with left aligning the buttons and maybe having them all the same size? I also notice the that browser title bars are much taller than normal mac application title bars (and again in Squeak 4.1 they are smaller and match the native windows). I know these are small things - but they detract from the good work that is happening - and I want to show newcomers something that they find cool too. If someone can point me to where to look for these things, I would gladly fix and test them - but I'm stumped (and I'm sure they could be fixed in 2 minutes by someone knowledgeable). Tim

April 26, 2010

Re: [Pharo-project] FFI in 1.1

by StÃ©phane Ducasse

On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: > Stef, > > I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. there are no such alien maintainers. There are us. > > Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Sunday, April 25, 2010 3:05 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI in 1.1 > > Probably. > There were some discussions that alien will be integrated / working also for the windows vm. > So we will see which one I will let people with more experience telling that to us. > > Stef > > On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: > >> >> >> On Sun, Apr 25, 2010 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 26, 2010

[Pharo-project] Metacello project dependencies

by Torsten Bergmann

When I load version "1.0-10517" of ConfigurationOfPharo in a clean core 1.0#10517 image it works. But when I use the "1.0-10517" version of Pharo as a prerequisite in a project (for instance Metasource) within the same image I get a "Name not found - ArchiveViewer" error. The config looks OK to me. I'm puzzled ... If you want to try, use https://gforge.inria.fr/frs/download.php/26790/Pharo-1.0.zip and evaluate: Gofer new squeaksource: 'MetaSource'; package: 'ConfigurationOfMetaSource'; load. ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.0-alpha3') load. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 25, 2010

Re: [Pharo-project] is MC and MCBrowser sending event when a package is created?

by Lukas Renggli

On Sunday, April 25, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > is MC and MCBrowser sending event when a package is created? Yes. > is it using/extending SystemChangeNotifier? No. You register using #addDependent: to the class side of MCWorkingCopy. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

April 25, 2010

Re: [Pharo-project] FFI in 1.1

by Schwab,Wilhelm K

Stef, I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI in 1.1 Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us. Stef On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: > > > On Sun, Apr 25, 2010 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

Re: [Pharo-project] [squeak-dev] Re: Need your help filling a FAQ

by Igor Stasenko

On 26 April 2010 00:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 April 2010 23:45, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Igor, >> >> One question I have is how your work compares to Exupery? >> > > Well, i missing the good Exupery description , on squeak source it says: > A bytecode compiler for Squeak, still an alpha project. It doesn't yet > do anything useful but it can compile most bytecodes. > Or from wiki page: > Exupery is a compiler written in Smalltalk that compiles bytecodes to > machine code. > > So, as you can see, an Exupery aims mainly towards turning a bytecode > into a native code, i.e. towards implementing a JIT. > It is important to understand that NativeBoost project having a bit > orthogonal (or more complementary) aim - to allow you to run an > arbitrary native code and speak directly to hardware, OS etc. > Ohh.. i guess you asked about Moebius project. Sorry. Moebius is much more ambitious project. It is a smalltalk environment , fully implemented in itself, i.e. which requires no VM and minimal glue code to run on target platform. While Exupery, is still using a 'VM' concept which interpreting the methods, while additionally providing facilities to optimize the system speed by jitting some methods. In moebius, all methods are initially contain a native code. There is no interpreter. Sure it can be added later (as for any other language interpreter btw), but that will not change the fact that system can sustain itself and run without a need of having VM. > > >> Adrian >> >> On Apr 25, 2010, at 22:21 , Igor Stasenko wrote: >> >>> On 25 April 2010 23:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> >>>>> (a)(Smalltalk parser) -> >>>> >>>> could you plug the IRBuilder >>> >>> yes i can! The Moebius parser designed by taking in mind, that it can >>> be used as a backend >>> for any kind of encoding. It recognizing a smalltalk syntax and >>> semantic elements and then passing the messages to encoder. >>> And encoder can be anything. It can encode the parsed data into any >>> kind of AST , its just needs to conform with parser's protocol, >>> but can use arbitrary data structures for building the method's AST. >>> Parser don't have _any_ assumptions, into what form an encoder >>> translating the parsed data. >>> >>> So, for instance, i can implement a syntax highlighting encoder, based >>> on this parser, without a need of having separate parser targeted only >>> for syntax highlighting (like SHParserST80) >>> >>>> >>>>> (b)(Native intermediate instructions >>>>> generator (compiler)) -> (c)(Native code translator) >>>>> -> (d)(AsmJit) >>>>> >>>>> I having a, b and d , but c is still not complete. >>>>> And sure thing, one can use it for own purposes , since Moebius >>>>> implemented purely in smalltalk, >>>>> and works in Squeak/Pharo, so potentially it can be retargeted to anything else. >>>>> >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 25, 2010