- Pharo-dev - lists.pharo.org

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

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

by Christophe Demarey

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] Check multiple boxes in TreeModel

by Yuriy Tymchuk

Or should I move to Glamour? On 28 Aug 2014, at 15:31, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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. > > Uko

Aug. 28, 2014

Check multiple boxes in TreeModel

by Yuriy Tymchuk

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. Uko

Aug. 28, 2014

Re: [Pharo-dev] Spec license

by S Krish

Will there be any interest in alternative declarative framework, mostly fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et als in 3.0 http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework… I can push this in with the required MIT license sign off as reqd. More importantly, move this framework to a more refactored cleaner state if there is a slight interest in alternatives. On Thu, Aug 28, 2014 at 5:51 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > No, it doesn't. > > We can improve Spec in the core, why wouldn't we be able to? > We use it in a lot of the tools, so, there are plenty of samples and > documentation exists. > > One can make sense of what's going on under the hood. > > Have a look at: (this is for Pharo 3.0) > > SpecInterpreter>>interpretASpec:selector: and ComposableModel + > NewValueHolder. > WindowModel is interesting to look into as well. > > The "famous" NewValueHolder is of interest too. > > > then implementors of defaultSpec provide a lot of specs to give to the > SpecInterpreter. > > Then one wants to look into the Spec-MorphicAdapters to see how Spec maps > its view on things with underlying Morphs (e.g. check the > MorphicDiffAdapter). > > We can only benefit by caring about this piece on our side, as there is > tremendous potential in being able to change the underlying system (e.g. > from Morphic to Bloc for example) in a piecemeal way, without breaking all > of the tools. > > Phil > > > On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> Does it really matter? >> If the external repository gets successfully relicensed, or Benjamin >> publishes new improvements as a separate, GPL-licensed change set, the end >> result is the same; >> no improvement he makes will make its way back into the versions in Core. >> >> I may not know his reasons, but I can certainly respect his wish that no >> further contributions are included in a core distribution. >> >> Whether to maintain/improve the current, MIT-licensed versions in Core >> without him, or unload it all and point potential users to the external >> library, is a separate decision. >> Though, from previous attempts, Iâd say the chances of success of an >> external UI-builder framework seeing actual use are rather slim. >> >> Cheers, >> Henry >> >> On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> > >> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f39… >> > >> > I think the license might need further improvements. >> > I've taken a look at the commit history, and it looks >> > to me like there is a licensing problem there. >> > I am no lawyer, so don't know what the >> > exact consequences of that are. >> > >> > The (MIT licensed) Pharo code was copied >> > to the repository without including the copyright >> > notice, as is required by the MIT license. >> > >> > For new contributions, you now have the >> > license agreements, and with git it is >> > perfectly clear what is new, and under >> > the new license, and what is old, and >> > can therefore also be used under the >> > old license. And AFAIK MIT license >> > is compatible with GPL. >> > >> > I have no clue as to the license status of >> > changes between the copying and the >> > relicensing. >> > >> > Of course copyright holding contributors can >> > decide to relicense. The contributors to the >> > Spec-* packages in the Pharo/Pharo30 repo >> > seem to be: >> > >> > AlainPlantec >> > AndreiChis >> > BenComan >> > BenjaminVanRyseghem >> > BernardoContreras >> > CamilloBruni >> > CamilleTeruel >> > ChristopheDemarey >> > ClementBera >> > DamienCassou >> > ErwanDouaille >> > EstebanLorenzano >> > GabrielOmarCotelli >> > GuillermoPolito >> > HernanMoralesDurand >> > IgorStasenko >> > LeoGassman >> > MarcusDenker >> > MartinDias >> > NicolaiHess >> > PabloHerrero >> > PavelKrivanek >> > PhilippeBack >> > RobertoMinelli >> > SeanDeNigris >> > SebastianTleye >> > StephaneDucasse >> > SvenVanCaekenberghe >> > TorstenBergmann >> > TudorGirba >> > YuriyTymchuk >> > >> > Stephan >> > >> > >> > >> > >> >> >

Aug. 28, 2014

Re: [Pharo-dev] Substitution of ' to " in TextEditor>>shiftEnclose

by J. Vuletich (mail lists)

Hi Folks, (below) Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > On Wed, Aug 27, 2014 at 4:27 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> I encountered this in Squeak too, because French keyboard is not better >> than german one :( >> >> Nicolas Cellier uploaded a new version of ST80 to project The Trunk: >> http://source.squeak.org/trunk/ST80-nice.136.mcz >> >> ==================== Summary ==================== >> >> Name: ST80-nice.136 >> Author: nice >> Time: 4 August 2011, 10:43:00.836 am >> UUID: 6f8b2f4c-8c8c-48a8-ba32- bb5b37d827d0 >> Ancestors: ST80-ul.135 >> >> #shiftEnclose: is hardcoding the keyboard layout, which is not >> compatible with foreign keyboards and modern VM, and prevents correct >> enclosing to work. > > Â > +1. Â This is the issue that must be fixed. Â It must be understood > properly (is the VM answering adequate information or not?). > Â The information provided by the VMs in keystroke events is not perfect, and it could be enhanced. I see 2 main problems (in what follows, $x denotes Character x, and [x] denotes the physical keyboard key labelled 'x'): Problem 1) On the mac, when control or command are pressed, for any keystroke the unshifted code is returned, even if shift is pressed. For instance, let's assume an US keyboard. So, [shift]+[,] generates $< and [shift]+[.] generates $>. If you run 'Sensor kbdTest' and press [shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,] or [command]+[shift]+[,] you get $,. This is bad, because to detect [command]+[<] or [control]+[<] you need to write code that not only needs to know about the platform, but also about the keyboard layout, as in many layouts $< is not generated by doing [shift]+[,], but by some other combination. The same happens with most non-alphabetic keys, that usually differ in different keyboard layouts. Problem 2) There is a completely separated issue, and it happens both in Windows and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code. So, [ctrl]+[c] generates code 3. This is consistent with the traditional meaning of the ctrl key (in dumb terminals and DOS), but it makes impossible for the image to tell (for example) between [ctrl]+[Enter] and [ctrl]+[m]. The image might want to use these keystrokes for different things, so it would be much better not to substract 64 in the VM and let the image handle it. I know it could be done by handling key down and key up events, but this would also require code that is not only platform dependent but also needs to know the mapping between key codes and characters in each platform. I haven't tested on Linux or platforms other than Windows and Mac, but things like these could also happen. In general, [control], [command] and [alt/option] should not affect the character code of a keystroke, they should only set the appropriate flag so the image can decide what to do with them. The character code should be the same as if [control], [command] and [alt/option] were not pressed. This is completely different for [shift], as [shift] does indeed modify the character generated, as [shift]+[8] means $* in some keyboards and $( on others. If [shift]+[someKey] is pressed, the keystroke character code should be the same as the user would get elsewhere in the platform, irrespectively of [control], [command] and/or [alt/option] being pressed or not. Fixing these, and making the behavior consistent between platforms, would enable a few simplifications in the image. It would also enable the use of some keystroke combinations involving [command] and/or [control] that are problematic today. > > best, Eliot Thanks, Juan Vuletich

Aug. 28, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram

by Alexandre Bergel

Thanks Damien! I am currently travelling. I will have a closer look at your fix next week. Thanks for your work! Cheers, Alexandre On Aug 26, 2014, at 9:38 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > â¦speaking of code changes, here's a small fix > > On 26 August 2014 15:41, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> On 26 August 2014 15:23, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Can you share what is necessary to reproduce the pictures youâve sent ? (e.g., PoissonDiscDistribution class) >> >> sure: >> >> Gofer new >> smalltalkhubUser: 'cdlm' project: 'Flatland'; >> package: 'PoissonDiscSampler'; >> load >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > <Roassal2-DamienPollet.449.mcz> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 28, 2014