August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Marcus Denker

On 28 Aug 2014, at 16:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> >>>> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>>>> MyClass class>>#compilerClass >>>>> ^ MySpecialCompiler >>>>> >>>> >>>> Iâve missed this feature. This is super cool! >>>> >>> >>> There is now in addition #compiler, an instance, not the class. >> >> Hum right... I should do the same thing with a #classSideCompiler then, right? >> > yesâ¦ but when #compiler is set, it should be valid for both instance and class side... or not: as it seems to never have applied to the class side, it should be fine to keep them separate. that is, #compiler applies to instance side, and a classSideCompiler applies to the class side by default people only override the instance side one, but when needed, they can override the classSide one, too. (e.g. when you do a DSL, you want to still have the #initialize on the class side be untouched smalltalk in most cases). Marcus

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Marcus Denker

On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> >>> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>>> MyClass class>>#compilerClass >>>> ^ MySpecialCompiler >>>> >>> >>> Iâve missed this feature. This is super cool! >>> >> >> There is now in addition #compiler, an instance, not the class. > > Hum right... I should do the same thing with a #classSideCompiler then, right? > yesâ¦ but when #compiler is set, it should be valid for both instance and class side... >> >> This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can do >> >> compiler >> "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done >> in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate >> long bytecodes" >> ^super compiler options: #(+ optionLongIvarAccessBytecodes) >> >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Igor Stasenko

On 28 August 2014 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > Hi all, > > With Opal, if you want to customize how methods are compiled into a class > you can override #compilerClass on class-side: > MyClass class>>#compilerClass > ^ MySpecialCompiler > > > Iâve missed this feature. This is super cool! > > > There is now in addition #compiler, an instance, not the class. > > Right. Factory method(s) like this are significantly more flexible, since implementor may want to provide a special way of initializing the compiler, you can't foresee via class standard '#new' protocol before hanging it over to user. Giving just a class, make things quite hard and limiting.. especially in situation when developer wants to make a subclass which carries additional state , which needs to be initialized properly. That's why, I prefer to use factory methods instead of 'SomethingClass' everywhere i need. > This is useful as you can set compiler options this way. e.g. > InstructionStream does not need to use a subclass but can do > > compiler > "The JIT compiler needs to trap all reads to instance variables of > contexts. As this check is costly, it is only done > in the long form of the bytecodes, which are not used often. In this > hierarchy we force the compiler to always generate > long bytecodes" > ^super compiler options: #(+ optionLongIvarAccessBytecodes) > > -- Best regards, Igor Stasenko.

Aug. 28, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by Tim Mackinnon

Kilon - it would be good if we could percevear to try and get a fix and detailed instructions for other less confident usersâ¦ At least test Benâs updated installer so we can clear this. I appreciate the aggravation you are putting up with. Tim On 28 Aug 2014, at 10:35, kilon alios <kilon.alios(a)gmail.com> wrote: > My work pc is dual boot to ubuntu and win 7 . I am not a fan of linux either, loads of problems there but nowhere near as bad as windoom. > > I need windoom because of a Greek OCR I use at work to scan legal documents. I have no choice other than to continue using it. > > I dont care what the corporate world does or the fact that almost 100% of my fellow lawyers use windoom and some still DOS. Thats their problem :D > > It would be nice to support what 95% of people use out there, but alas I cant take it anymore. Coding should be fun, Windoom kills my inner child. Sorry for those that have to tolerate this crap, but I am lucky enough not to . > > /ranting off > > > On Thu, Aug 28, 2014 at 11:50 AM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > ok thing get worse and worse > > I try to run pharo as administrator and pharo opens and exits immediately , it creates a stderr which contains the following > > http://pastebin.com/v9Hpx9pK > > I found the folder you mentioned and I deleted it , now pharo does not open at all even when run without "run as administrator" > Boy I hate Windoom. I also tried Tim link , nothing, pharo opens but does nothing, no gui, nothing. I know it opens because i can see its process in the task manager which i have to terminate manually. > I do all my coding and art on macos, I only have windows at work so i can test my code on windoom too, but this was the last straw, I had enough with this uber crappy OS for 17 years now. I am dropping support for it and sticking to MacOS only. > Thanks guys for your help but it does not worth it. I hope no other windows user experience my problem. > > > I empathize. I've been a Linux advocate for years, but never made the full desktop switch since I needed a Windows system for corporate compatibility. Then I got a mac-mini to experiment with iPad Mobile Device Management, and found it easier to get Latex working on it than on Windows (for processing Pillar output), and now I find myself using it for Pharo more every day, and my Windows box is starting to be neglected (except I still need to migrate my old Thunderbird email archive). > > However success in the corporate world still hinges a lot on Windows compatibility. I will still have a go at updating PharoLauncher Installer to avoid this problem. > cheers, Ben > > P.S. @Tim, Your alternate-VM feature sound interesting. I'll check it out. > >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Camille Teruel

On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> Hi all, >>> >>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>> MyClass class>>#compilerClass >>> ^ MySpecialCompiler >>> >> >> Iâve missed this feature. This is super cool! >> > > There is now in addition #compiler, an instance, not the class. Hum right... I should do the same thing with a #classSideCompiler then, right? > > This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can do > > compiler > "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done > in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate > long bytecodes" > ^super compiler options: #(+ optionLongIvarAccessBytecodes) >

Aug. 28, 2014

Re: [Pharo-dev] Check multiple boxes in TreeModel

by Yuriy Tymchuk

`autoMultiSelection: true` does the job Does anybody know what #removeOnlyLastSelected: is for? Because itâs also used by Komitterâ¦ Uko On 28 Aug 2014, at 15:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Iâll take a look. > > Thanks Christophe! > > On 28 Aug 2014, at 15:37, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > >> >> Le 28 aoÃ»t 2014 Ã 15:31, Yuriy Tymchuk a Ã©crit : >> >>> HI guys, >>> >>> is it possible? Iâve tried `autoDeselection: false`, `multiSelection: true`â¦ and it continues to deselect selected items :(. Maybe there is any kind of example how to do a classic checkbox tree? For example if we have filesystem and want to select which items to backup. >> >> I did not check the code but at least Komitter do the thing you want to do. >> It should be easy to trigger out the way to configure your treeModel from there. >> >> Christophe >> > >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Marcus Denker

On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> Hi all, >> >> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >> MyClass class>>#compilerClass >> ^ MySpecialCompiler >> > > Iâve missed this feature. This is super cool! > There is now in addition #compiler, an instance, not the class. This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can do compiler "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate long bytecodes" ^super compiler options: #(+ optionLongIvarAccessBytecodes)

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Yuriy Tymchuk

On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi all, > > With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: > MyClass class>>#compilerClass > ^ MySpecialCompiler > Iâve missed this feature. This is super cool! > However this custom compiler is not taken into account when compiling methods on the class-side: > MyClass class compilerClass ---> OpalCompiler > I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass. > Is it on purpose or is it a bug? > > Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes? > My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that. > So I propose to add a method #classSideCompilerClass: > Class>>#classSideCompilerClass > ^ self compilerClass > > Then compilerClass can be implemented for metaclasses: > Metaclass>>#compilerClass > ^ self instanceSide classSideCompilerClass > > Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice. > > Cheers, > Camille >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Camille Teruel

Ok then, here the bug entry https://pharo.fogbugz.com/f/cases/13938/Opal-custom-compilers-and-class-sid… Slice in inbox On 28 aoÃ»t 2014, at 10:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> Hi all, >> >> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >> MyClass class>>#compilerClass >> ^ MySpecialCompiler >> >> However this custom compiler is not taken into account when compiling methods on the class-side: >> MyClass class compilerClass ---> OpalCompiler >> I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass. >> Is it on purpose or is it a bug? >> > This is a bug, clearly. > >> Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes? > I hope notâ¦ but the, could be interesting (e.g. when experimenting). > If the overhead is not large, this would be nice. > >> My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that. >> So I propose to add a method #classSideCompilerClass: >> Class>>#classSideCompilerClass >> ^ self compilerClass >> >> Then compilerClass can be implemented for metaclasses: >> Metaclass>>#compilerClass >> ^ self instanceSide classSideCompilerClass >> >> Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice. > > Yes, this looks good! > > Marcus

Aug. 28, 2014

Re: [Pharo-dev] Check multiple boxes in TreeModel

by Yuriy Tymchuk

Iâll take a look. Thanks Christophe! On 28 Aug 2014, at 15:37, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Le 28 aoÃ»t 2014 Ã 15:31, Yuriy Tymchuk a Ã©crit : > >> HI guys, >> >> is it possible? Iâve tried `autoDeselection: false`, `multiSelection: true`â¦ and it continues to deselect selected items :(. Maybe there is any kind of example how to do a classic checkbox tree? For example if we have filesystem and want to select which items to backup. > > I did not check the code but at least Komitter do the thing you want to do. > It should be easy to trigger out the way to configure your treeModel from there. > > Christophe >

Aug. 28, 2014