- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40193 Home: https://github.com/pharo-project/pharo-core

Aug. 28, 2014

Re: [Pharo-dev] Spec license

by Henrik Johansen

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

Spec license

by Stephan Eggermont

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 Henrik Johansen

On 28 Aug 2014, at 10:58 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 27 Aug 2014, at 9:19 , Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Of course, similar code and change in Morphic, see bottom of change report http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160926.h… and follow links. >> >> This came after http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160923.h… >> >> But then, there were some complaints of English keyboard users... >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160968.h… >> >> and then later http://forum.world.st/Re-squeak-dev-shift-enclose-broken-in-trunk-td4543316… >> >> I don't remember how the issue ended, or even if it properly ended... >> (That's where an issue tracker should shine, but Squeak one is not really used/maintained). > > Thatâs not really a bug in the VM or anything, but a lossy translation from Ctrl -> Shift + Alt in the imageâ¦ > Only the modifier keys are â¦ modified, while the key character is left unchanged. > Thus, when one uses Ctrl + â (on those layouts where " is its shifted value), the = â ifTrue: [:= "] part is a hack around that, hardcoded to a single layout. > When using Shift + â , the VM return the keyValue of ", and no translation is needed. > > My 2C: Remove the workarounds, as well as the option of translating Ctrl -> Shift + Alt. > In order for it to work *properly* without external hacks, youâd need to implement all keyboard layouts image side, and translate the key character as well as modifier keys. > The alternative would be to change the VM to include the properly shifted character in each keyboard event, which seems a bit excessive for supporting such a feature. (If such support functions even exist) > > Cheers, > Henry > AFAICT, Pharo already removed this option, so removing shiftEnclose: shouldnât have any nasty lingering side-effects. Itâs a relatively small change as well, I attached the .cs to the existing issue: https://pharo.fogbugz.com/f/cases/4646/shiftEnclose-shall-not-hardcode-the-… Comments like these (from TextEditor >> initializeBasicShiftCmdKeyShortcuts) just make me wince: "Note: Command key overrides shift key, so, for example, cmd-shift-9 produces $9 not $(" '9[,''' do: [ :char | cmdMap at: (char asciiValue + 1) put: #shiftEnclose: ]. "({< and double-quote" "Note: Must use cmd-9 or ctrl-9 to get '()' since cmd-shift-9 is a Mac FKey command.Â» Why would you ever need use command + shift instead of just shift to make those characters? I guess Cmd -> Ctrl -> Shift + Alt might be an option in Squeakâ¦ but why not just use shift if thatâs what you wanted in the first place? (Full disclosure: on my keyboard layout, '(' is on 8) Cheers, Henry

Aug. 28, 2014

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

by kilon alios

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] Substitution of ' to " in TextEditor>>shiftEnclose

by Henrik Johansen

On 27 Aug 2014, at 9:19 , Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Of course, similar code and change in Morphic, see bottom of change report http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160926.h… and follow links. > > This came after http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160923.h… > > But then, there were some complaints of English keyboard users... > http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160968.h… > > and then later http://forum.world.st/Re-squeak-dev-shift-enclose-broken-in-trunk-td4543316… > > I don't remember how the issue ended, or even if it properly ended... > (That's where an issue tracker should shine, but Squeak one is not really used/maintained). Thatâs not really a bug in the VM or anything, but a lossy translation from Ctrl -> Shift + Alt in the imageâ¦ Only the modifier keys are â¦ modified, while the key character is left unchanged. Thus, when one uses Ctrl + â (on those layouts where " is its shifted value), the = â ifTrue: [:= "] part is a hack around that, hardcoded to a single layout. When using Shift + â , the VM return the keyValue of ", and no translation is needed. My 2C: Remove the workarounds, as well as the option of translating Ctrl -> Shift + Alt. In order for it to work *properly* without external hacks, youâd need to implement all keyboard layouts image side, and translate the key character as well as modifier keys. The alternative would be to change the VM to include the properly shifted character in each keyboard event, which seems a bit excessive for supporting such a feature. (If such support functions even exist) Cheers, Henry

Aug. 28, 2014