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

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

Re: [Pharo-dev] Looking for PhD students

by Craig Latta

Hi Michele-- I'm very interested in pursuing a PhD. I started developing with Smalltalk while studying music and computer science at the University of California at Berkeley. I went on to develop interactive audio tools at Atari Games, consumer electronics applications at Interval Research, and AI research at the IBM T.J. Watson Research Center, all with Smalltalk. I've participated in the Squeak and Pharo communities since they began, and have served on the Squeak board for several years. I wrote the Flow, Naiad, and Spoon frameworks, for Smalltalk streaming (including remote messaging), change management (including team collaboration), and minimal system deployment (including distributed operation). I would love to pursue them in the context of a PhD. There's more information about them on my blog[1] and website[2]. I use them in my own work with remote music collaboration, improvisation, and livecoding[3]. I look forward to speaking with you! thanks, -C [1] http://thiscontext.com [2] http://netjam.org/cv [3] http://toplap.org -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Aug. 28, 2014

Re: [Pharo-dev] Spec license

by phil＠highoctane.be

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] athens wrapper for (Form-)Canvas

by Igor Stasenko

On 27 August 2014 22:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > That is cool. What I suggest is to get it out there and then we work with > you to tell you the use cases and we evolve the API from there. > > Okay. > Cheers, > Doru > > > On Wed, Aug 27, 2014 at 5:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 27 August 2014 09:42, stepharo <stepharo(a)free.fr> wrote: >> >>> Igor >>> >>> we should integrate TxText as soon as the new integration handle >>> configurations (normally next week). >>> So can you get prepared? >>> >>> >> I can make configuration with latest versions.. >> but that won't make things more 'prepared' in aspect that i am still did >> not took time to think about high-level API , so there's almost none at the >> moment.. and it is still a big question to me, how it should look like. >> >> i need a list of requirements from perspective of text editor widget, to >> at least know what API should be there.. >> because if people start using it without API, then it will be hard to do >> any changes later, once people integrate it into own projects.. >> i just don't want the complexity overflow us, we should keep things >> simple enough, hiding implementation details behind. >> >> We should discuss that.. >> because yeah.. you can create morph, place it on screen.. but that don't >> makes it easy or convenient to use. >> >> Stef >>> >>> >>> On 26/8/14 17:43, Igor Stasenko wrote: >>> >>> >>> >>> >>> On 26 August 2014 00:24, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> I tried an alternative approach for rendering Morphs on athens without >>>> implementing drawOnAthensCanvas for every morph: >>>> >>>> 13866 <https://pharo.fogbugz.com/default.asp?13866> >>>> AthensFormCanvasWrapper >>>> >>>> still struggling with the text rendering. Yet I am not sure what is the >>>> better approach. >>>> >>> >>> A new text model, which i am working on :) >>> >>> >>>> >>>> Nicolai >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Best regards, Igor Stasenko.

Aug. 28, 2014

[pharo-project/pharo-core] 3f74b0: 40193

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3f74b0372265ac28efb5605ef629b31ae5312694 https://github.com/pharo-project/pharo-core/commit/3f74b0372265ac28efb5605e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-28 (Thu, 28 Aug 2014) Changed paths: M AsmJit-Tests.package/AJx64AssemblerTests.class/instance/tests/testAssembly3.st A AsmJit-Tests.package/AJx64AssemblerTests.class/instance/tests/testStringOps64Mnemonics.st A AsmJit-Tests.package/AJx86AssemblerTests.class/instance/tests-FPU/testMOVCMPSD.st A AsmJit-Tests.package/AJx86AssemblerTests.class/instance/tests/testStringOpMnemonics.st M AsmJit-x86.package/AJx64InstructionDescription.class/instance/code emitting/emitalu_operand1_operand2_operand3_.st M AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitOperandSizeOverridePrefix_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexForInteger_op2_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexForOp1_op2_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexForSingleOperand_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexPrefixW_R_X_B_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexRM_regCode_rm_.st A AsmJit-x86.package/AJx86Instruction.class/instance/code generation - prefixes/emitRexR_opReg_regCode_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexForInteger_op2_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexForOp1_op2_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexForSingleOperand_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexPrefixW_R_X_B_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexRM_regCode_rm_.st R AsmJit-x86.package/AJx86Instruction.class/instance/code generation/emitRexR_opReg_regCode_.st A AsmJit-x86.package/AJx86Instruction.class/instance/prefixes/operandSizeOverridePrefix.st A AsmJit-x86.package/AJx86InstructionDescription.class/class/accessing/instructionsAmbiguous.st M AsmJit-x86.package/AJx86InstructionDescription.class/class/initialization/initInstructions.st M AsmJit-x86.package/AJx86InstructionDescription.class/class/initialization/instructionData.st M AsmJit-x86.package/AJx86InstructionDescription.class/class/initialization/instructionsOther.st A AsmJit-x86.package/AJx86InstructionDescription.class/class/initialization/instructionsStrings.st M AsmJit-x86.package/AJx86InstructionDescription.class/instance/code emitting/emittest_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuMovD_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuMovQ_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuMov_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuPextr_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuPrefetch_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuRm3DNow_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmuRmImm8_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting - mmu/emitmmurmi_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting-dispatch/emitsddisambiguate_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuMovD_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuMovQ_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuMov_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuPextr_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuPrefetch_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuRm3DNow_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmuRmImm8_operand1_operand2_operand3_.st R AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitmmurmi_operand1_operand2_operand3_.st A AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st M Refactoring-Tests-Core.package/RBRefactoryTestDataApp.class/instance/as yet unclassified/demoRenameMethod_PermuteArgs_.st M Refactoring-Tests-Core.package/RBRenameMethodTest.class/instance/tests/testRenameMethodPermuteArgs.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script193.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40193.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40193 13413 Support string operations in AsmJit https://pharo.fogbugz.com/f/cases/13413 13926 Assign to args in RBRefactoryTestDataApp>>#demoRenameMethod:PermuteArgs: https://pharo.fogbugz.com/f/cases/13926 http://files.pharo.org/image/40/40193.zip

Aug. 28, 2014