- Pharo-dev - lists.pharo.org

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

> I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports). I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches. Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 26, 2010

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

by Igor Stasenko

On 26 April 2010 11:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 April 2010 11:17, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> 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? >> > You are right , of course there are some synergy. Both projects in one > or another way dealing with native code. > > But if you dig a bit deeper , you'll find some differences. > > 1. > - NativeBoost plugin requires very small changes to existing VMs. > I mentioned only one change: allow a code execution for object memory. > To enable it, it requires changing 2 lines of code in sqWin32Alloc.c file > > Â -- VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_READWRITE) > Â ++ VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_EXECUTE_READWRITE) > > (similar amount of changes required for other platforms). > > A plugin, which is a very small thing (only 2 primitives) can be > shipped as external one. > done! > > - Exupery requires a lot more changes to VM. Its even having own VMMaker. > > 2. > - Exupery allocates and uses a separate memory region for storing a > native code there. > So, it requires and additional efforts to manage this memory. > > - NativeBoost uses an object memory (a CompiledMethods for storing a > native code). > And so, it requres no additional efforts to manage a memory. GC is > your friend :) > > 3. > - (last time i seen) Exupery compiler produces a location-dependent > code. So, if you relocate the native code, you have to alter all call > labels, literals and so on. This adds an additional logic to code, in > order to handle that. Sure it saves some CPU cycles (relative calls is > a bit cheaper), except from cases when you moving the code regularily > ;) > > - NativeBoost is intentionally puts you in costraints that you should > not use/produce a location-dependent code i.e. > all jumps should be relative and local to same routine, all calls > should be absolute. > NativeBoost handles the native code relocation automagically and don't > needs an extra effort. > 4. -(last time i seen) Exupery flushing the native code periodically. Actually its using a memory for native code in a cache-like fashion - NativeBoost flushing the native code only once: at image startup. Or on user request. there can be more differences but i think, i presented enough facts , which explaining why i invented own wheel instead of using existing one. >> 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 >> >> >> _______________________________________________ >> 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 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 Tim Mackinnon

I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports). I'm interested in your changes so that I can start to figure out how some of this stuff is done so that maybe one day I can contribute something helpful. Thanks for looking at this though - it does help. Tim On 26 Apr 2010, at 08:47, Lukas Renggli wrote: > 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 > > _______________________________________________ > 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] About feedback and request for enh

by Tim Mackinnon

Stef - can you update the template in the Google Issue tracker - it offers some instructions - and your text would be good in that template. Also while it has good instructions on how to get the "Pharo Core Version" however I am never sure how to definitively check the VM version (other than look on my file system). Why not add the following after the first sentence: We are currently working on version 1.1, so please verify your issue in <put version number you want us to use> before reporting it. The text in the issue template is as follows : If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: <core, dev or web> Pharo core version: <copy from World/System/About> Virtual machine used: <ex: pharo-vm-0.15.2f-linux> Class browser used if applicable: <ex: O2PackageBrowserAdaptor. If you don't know, print "SystemBrowser default"> Steps to reproduce: 1. 2. 3. Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image): On 26 Apr 2010, at 09:22, StÃ©phane Ducasse wrote: > Hi all > > We appreciate feedback and request now to avoid us to be flooded here is a proposal. > > - It does not really make sense to comment on 1.0 without checking 1.1 > We will not change 1.0. So better check 1.1 > > - We do not have that many resources so if you want something, it is also important > that you see how you can help. May be you do not know directly the topic but > by helping on another front, people may have more time for this one. > > - Bugs can be entered for 1.0 but again check 1.1 because only REALLY severe bugs will get fixed > in 1.0. > > Stef > _______________________________________________ > 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] [squeak-dev] Re: Need your help filling a FAQ

by Igor Stasenko

On 26 April 2010 11:17, Adrian Lienhard <adi(a)netstyle.ch> wrote: > 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? > You are right , of course there are some synergy. Both projects in one or another way dealing with native code. But if you dig a bit deeper , you'll find some differences. 1. - NativeBoost plugin requires very small changes to existing VMs. I mentioned only one change: allow a code execution for object memory. To enable it, it requires changing 2 lines of code in sqWin32Alloc.c file -- VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_READWRITE) ++ VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_EXECUTE_READWRITE) (similar amount of changes required for other platforms). A plugin, which is a very small thing (only 2 primitives) can be shipped as external one. done! - Exupery requires a lot more changes to VM. Its even having own VMMaker. 2. - Exupery allocates and uses a separate memory region for storing a native code there. So, it requires and additional efforts to manage this memory. - NativeBoost uses an object memory (a CompiledMethods for storing a native code). And so, it requres no additional efforts to manage a memory. GC is your friend :) 3. - (last time i seen) Exupery compiler produces a location-dependent code. So, if you relocate the native code, you have to alter all call labels, literals and so on. This adds an additional logic to code, in order to handle that. Sure it saves some CPU cycles (relative calls is a bit cheaper), except from cases when you moving the code regularily ;) - NativeBoost is intentionally puts you in costraints that you should not use/produce a location-dependent code i.e. all jumps should be relative and local to same routine, all calls should be absolute. NativeBoost handles the native code relocation automagically and don't needs an extra effort. > 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 > > > _______________________________________________ > 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

Re: [Pharo-project] FFI in 1.1

by Igor Stasenko

On 26 April 2010 10:57, Lukas Renggli <renggli(a)gmail.com> wrote: > Igor, > > Looks cool, but I really would like to know the exact difference to Exupery? > > For what I understand NativeBoost is no different to Exupery's > low-level code generation infrastructure. You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :) > Check out the Exupery > documentation: <http://goran.krampe.se/exuperyDesign.pdf>. > Thanks, i read it before. I know many things about Exupery. I even contributed to Exupery codebase once upon a time. > Some more questions about NativeBoost: > > - How do I send a message? > You don't. Think of a native code as a primitive. > - How do I evaluate a block passed as argument? > Same as above. > - How do I access the VM state? > Through interpreterProxy functions. In same way as any plugin does. Exupery having a good extension (which i contributed to it btw), which allows you to retrieve any VM symbol address, so then you can call any VM function or access any of its global state directly. But currently i'm trying to stay away from changing VM, because i want my plugin to work on usual VMs. > Lukas > > On 26 April 2010 09:38, Igor Stasenko <siguctua(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 > > _______________________________________________ > 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] About feedback and request for enh

by StÃ©phane Ducasse

Hi all We appreciate feedback and request now to avoid us to be flooded here is a proposal. - It does not really make sense to comment on 1.0 without checking 1.1 We will not change 1.0. So better check 1.1 - We do not have that many resources so if you want something, it is also important that you see how you can help. May be you do not know directly the topic but by helping on another front, people may have more time for this one. - Bugs can be entered for 1.0 but again check 1.1 because only REALLY severe bugs will get fixed in 1.0. Stef

April 26, 2010

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