February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] pushed sound + sound interface from pharoNonCorePackage to PharoSound

by StÃ©phane Ducasse

For your info I pushed pushed sound + sound interface from pharoNonCorePackage to PharoSound Next step: merged and have a look at the idea of henrik fix pharo-dev to load from pharoSound Stef

Feb. 3, 2011

Re: [Pharo-project] [ANN]Keymappings Settings Integration

by StÃ©phane Ducasse

Feedback randomly generated :) - sixxContentOn: aStream indent: level context: dictionary ?? Do we want to rely on SIXX? No! - Please add one comment per class! - run SmallLint initialize categoryContainer ifNil: [ categoryContainer := KeymapManager default ] => should do a super initialize - move deprecated method to 'deprecated' category KMBuilder - Cant you remove KMCmd and KMMeta Looks to me that you could do the same with a sharedPool or moving the class methods somewhere else. - can you have morph/text specific bindings? I commited some simple changes Stef

Feb. 3, 2011

Re: [Pharo-project] [ANN]Keymappings Settings Integration

by StÃ©phane Ducasse

+ 1 On Feb 3, 2011, at 10:27 AM, Alain Plantec wrote: > Hi Guillermo, > really cool, thanks. > I have few remarks bit here is the more important one for now (I'm very busy, i will give you more feedbacks later) > > The problem of your implementation is that the declaration of kmappings are all centralized in KMToolsDefaultSettings > and that you introduce a dependency between tools and keymappings. > Imagine i've my tool and I want to declare a key mapping for it, then I have to change KMToolsDefaultSetting class. > If my package for my tool is removed, then, again KMToolsDefaultSetting must be changed. > I think the key mappings should be declared by tool packages independently as it is for settings > without any dependency with the Keymapping package. > > I would integrate more the declaration with the system settings > > I give only a possible declaration here: > -------------- > ToolSetKeyMapping class>>keyMappingsOn: aBuilder > <systemsettings> > ... > with: [ > (aBuilder shortcut: #openClassBrowser) > target: ToolSet; > default: 'alt t, alt b'; > description: 'Open the class browser' translated. > (aBuilder shortcut: #openMonticelloBrowser) > target: ToolSet; > default: 'alt t, alt m'; > description: 'Open Monticello' translated] > --------------- > Then, SettingTreeBuilder could be improved in order to take into account the #shortcut: message. > For the rest, I can help you /do with your help if you need :) > > Thanks again. > Alain > > > > > Le 03/02/2011 03:46, Guillermo Polito a Ã©crit : >> Hi! >> >> I refactored a little widget Keymappings had to use it into Settings. See screenshots attached. >> >> The main idea is to "type" the shortcut once the widget has focus. After that, doing a secondary clic there is a context menu to accept, clear or cancel the changes. >> >> Actual version of Keymappings presents a shortcut for opening a browser, a monticello browser and a test runner just to show how it works. I expect that in no more than 2 weeks I'll have Editors integration so we can configure the editor shortcuts :). >> >> I would **REALLY LOVE** to have some feedback :). >> >> Who wants to load actual version of Keymappings can evaluate: >> >> Gofer it >> squeaksource: 'Keymapping'; >> package: 'ConfigurationOfKeymapping'; >> load. >> >> (ConfigurationOfKeymapping project version:'1.3') load. >> >> >> Cheers, >> Guille >> >> PS: I've tested it only in Pharo 1.2 Core. > >

Feb. 3, 2011

Re: [Pharo-project] [ANN]Keymappings Settings Integration

by StÃ©phane Ducasse

excellent idea On Feb 3, 2011, at 9:23 AM, Fernando Olivero wrote: > Hi Guillermo, nice work! > I'm looking forward to compare your code against mine, and try to > detect room for improvements/merging the approaches. > Fernando > > > On Thu, Feb 3, 2011 at 3:46 AM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> Hi! >> >> I refactored a little widget Keymappings had to use it into Settings. See >> screenshots attached. >> >> The main idea is to "type" the shortcut once the widget has focus. After >> that, doing a secondary clic there is a context menu to accept, clear or >> cancel the changes. >> >> Actual version of Keymappings presents a shortcut for opening a browser, a >> monticello browser and a test runner just to show how it works. I expect >> that in no more than 2 weeks I'll have Editors integration so we can >> configure the editor shortcuts :). >> >> I would **REALLY LOVE** to have some feedback :). >> >> Who wants to load actual version of Keymappings can evaluate: >> >> Gofer it >> squeaksource: 'Keymapping'; >> package: 'ConfigurationOfKeymapping'; >> load. >> >> (ConfigurationOfKeymapping project version:'1.3') load. >> >> >> Cheers, >> Guille >> >> PS: I've tested it only in Pharo 1.2 Core. >> >

Feb. 3, 2011

Re: [Pharo-project] [squeak-dev] Accessing external resources in a cross-platform way

by StÃ©phane Ducasse

Ok I published everything to Filesystem which BTW was dead since 2004! Let us see what it will change. Stef >> Hernan >> >> I'm documenting and reorganizing and writing more tests for FS. >> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is >> available at: >> PharoTaskForces >> if you want to integrate/publish your code there, then you are welcomed. >> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api >> like workingDirectory returning a path and calling it workingDirectoryPath >> and push FS in Pharo. Of course, people may probably complain but we will do it. >> > > > How about using open repo.. not pharo-specific? > > MCHttpRepository > location: 'http://www.squeaksource.com/fs' > user: '' > password: '' > > I see that FS is quite easy to port over forks/dialects. > So, with some effort we can make it easily available across many > smalltalk platforms. > It will benefit not only Pharo (yes, Pharo could be a testbed for new > filesystem), > but then if people will want to port it on another platform, they will > have to just get in and start hacking there, > without using controversial repository (PharoTaskForces) , because it > means that this stuff is only for Pharo. > >> Stef >> >> On Feb 3, 2011, at 1:01 AM, HernÃ¡n Morales Durand wrote: >> >>> I've just implemented an initial release on top of FileSystem and >>> ProcessWrapper (it uses some bit of Grease too). This is how it works >>> in Windows: >>> >>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve " >>> C:\WINDOWS\system32\notepad.exe " >>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve " >>> C:\WINDOWS\system32\X264VFW.DLL " >>> ( FSLocator userBinaries / 'excel.exe' ) resolve " C:\Archivos de >>> programa\Microsoft Office\OFFICE11\EXCEL.EXE " >>> ( FSLocator userBinaries / 'firefox.exe' ) resolve " C:\Archivos de >>> programa\Mozilla Firefox\firefox.exe" >>> >>> So #sysEnvBinaries search in the OS PATH environment variable >>> locations (which is usually pretty fast) and #userBinaries in the >>> "program files" locations (it could be slow depending the amount of >>> entries). It's only tested under Windows, IIRC user binaries in Unix >>> are inside "/usr/local/bin" but you may tweak it to other locations, I >>> have no access to a Unix or MacOS. Feel free to suggest or add any >>> enhacements you like. >>> Cheers, >>> >>> HernÃ¡n >>> >>> 2011/1/28 Colin Putney <colin(a)wiresong.com>: >>>> On Fri, Jan 28, 2011 at 9:17 AM, HernÃ¡n Morales Durand >>>> <hernan.morales(a)gmail.com> wrote: >>>>> Thanks David, >>>>> >>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/ >>>>> it seems related in some way too >>>> >>>> Yes, FileSystem does attempt to provide a cross-platform way to >>>> resolve paths that are system-dependent. It doesn't include a way to >>>> search for executables, although that's a good feature idea. As David, >>>> mentioned you probably want to get the value of the PATH environment >>>> variable, and use that for your search. That will handle cross-host >>>> differences as well as cross-platform issues. >>>> >>>> Colin >>>> >>>> >>> <Fsextensions-hfm.2.mcz> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 3, 2011

[Pharo-project] About FileSystem

by StÃ©phane Ducasse

Hi guys Igor convinced me to publish filesystem into the squeaksource Filesystem so that others people can not feel that we are stealing it from colin. Now since we want it as a fondation for the our system, we should invest on it. and this is what I'm doing. So here is what I did - fetched all the versions from colin, lukas, pharotaskforces - pushed all the versions to squeaksource/Filesystem - pushed all the versions to pharoTaskForces Now I will publish to squeaksource/Filesystem. If people want to join this is open and free. Stef

Feb. 3, 2011

Re: [Pharo-project] [ANN]Keymappings Settings Integration

by Alain Plantec

Hi Guillermo, really cool, thanks. I have few remarks bit here is the more important one for now (I'm very busy, i will give you more feedbacks later) The problem of your implementation is that the declaration of kmappings are all centralized in KMToolsDefaultSettings and that you introduce a dependency between tools and keymappings. Imagine i've my tool and I want to declare a key mapping for it, then I have to change KMToolsDefaultSetting class. If my package for my tool is removed, then, again KMToolsDefaultSetting must be changed. I think the key mappings should be declared by tool packages independently as it is for settings without any dependency with the Keymapping package. I would integrate more the declaration with the system settings I give only a possible declaration here: -------------- ToolSetKeyMapping class>>keyMappingsOn: aBuilder <systemsettings> ... with: [ (aBuilder shortcut: #openClassBrowser) target: ToolSet; default: 'alt t, alt b'; description: 'Open the class browser' translated. (aBuilder shortcut: #openMonticelloBrowser) target: ToolSet; default: 'alt t, alt m'; description: 'Open Monticello' translated] --------------- Then, SettingTreeBuilder could be improved in order to take into account the #shortcut: message. For the rest, I can help you /do with your help if you need :) Thanks again. Alain Le 03/02/2011 03:46, Guillermo Polito a Ã©crit : > Hi! > > I refactored a little widget Keymappings had to use it into Settings. > See screenshots attached. > > The main idea is to "type" the shortcut once the widget has focus. > After that, doing a secondary clic there is a context menu to accept, > clear or cancel the changes. > > Actual version of Keymappings presents a shortcut for opening a > browser, a monticello browser and a test runner just to show how it > works. I expect that in no more than 2 weeks I'll have Editors > integration so we can configure the editor shortcuts :). > > I would **REALLY LOVE** to have some feedback :). > > Who wants to load actual version of Keymappings can evaluate: > > Gofer it > squeaksource: 'Keymapping'; > package: 'ConfigurationOfKeymapping'; > load. > > (ConfigurationOfKeymapping project version:'1.3') load. > > > Cheers, > Guille > > PS: I've tested it only in Pharo 1.2 Core.

Feb. 3, 2011

Re: [Pharo-project] [squeak-dev] Accessing external resources in a cross-platform way

by Igor Stasenko

On 3 February 2011 09:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hernan > > I'm documenting and reorganizing and writing more tests for FS. > I contacted colin several times but got no feedback. The version that we will integrate in Pharo is > available at: > Â Â Â Â PharoTaskForces > Â Â Â Â if you want to integrate/publish your code there, then you are welcomed. > We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api > like workingDirectory returning a path and calling it workingDirectoryPath > and push FS in Pharo. Of course, people may probably complain but we will do it. > How about using open repo.. not pharo-specific? MCHttpRepository location: 'http://www.squeaksource.com/fs' user: '' password: '' I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo. > Stef > > On Feb 3, 2011, at 1:01 AM, HernÃ¡n Morales Durand wrote: > >> I've just implemented an initial release on top of FileSystem and >> ProcessWrapper (it uses some bit of Grease too). This is how it works >> in Windows: >> >> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve Â " >> C:\WINDOWS\system32\notepad.exe " >> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve Â " >> C:\WINDOWS\system32\X264VFW.DLL " >> ( FSLocator userBinaries / 'excel.exe' ) resolve Â Â Â Â Â Â Â " C:\Archivos de >> programa\Microsoft Office\OFFICE11\EXCEL.EXE " >> ( FSLocator userBinaries / 'firefox.exe' ) resolve Â Â Â Â Â Â " C:\Archivos de >> programa\Mozilla Firefox\firefox.exe" >> >> So #sysEnvBinaries search in the OS PATH environment variable >> locations (which is usually pretty fast) and #userBinaries in the >> "program files" locations (it could be slow depending the amount of >> entries). It's only tested under Windows, IIRC user binaries in Unix >> are inside "/usr/local/bin" but you may tweak it to other locations, I >> have no access to a Unix or MacOS. Feel free to suggest or add any >> enhacements you like. >> Cheers, >> >> HernÃ¡n >> >> 2011/1/28 Colin Putney <colin(a)wiresong.com>: >>> On Fri, Jan 28, 2011 at 9:17 AM, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com> wrote: >>>> Thanks David, >>>> >>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/ >>>> it seems related in some way too >>> >>> Yes, FileSystem does attempt to provide a cross-platform way to >>> resolve paths that are system-dependent. It doesn't include a way to >>> search for executables, although that's a good feature idea. As David, >>> mentioned you probably want to get the value of the PATH environment >>> variable, and use that for your search. That will handle cross-host >>> differences as well as cross-platform issues. >>> >>> Colin >>> >>> >> <Fsextensions-hfm.2.mcz> > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 3, 2011

Re: [Pharo-project] Build failed in Hudson: Pharo 1.2 #114

by Marcus Denker

On Feb 3, 2011, at 9:06 AM, Torsten Bergmann wrote: > Looks like this comes from http://code.google.com/p/pharo/issues/detail?id=3623 and the changes on ConfigurationOfOmniBrowser in version 1.2.3 > > However: the config looks good to me since the '1.2-baseline' (which is used in the 1.2.3 version) looks like this: > > package: 'OCForOB' with: [ > spec repository: 'http://www.squeaksource.com/OCompletion'; > > > and when I manually load > > (ConfigurationOfPharo project version: '1.2-beta2') load > > it works without a problem. Can you start a new build on Hudson > to see if it is still a problem? Or try a manual build on the > machine. I started a build. > > How does '/builds/workspace/Pharo 1.2/Pharo-1.2/Pharo-1.2.st' look > like? > attached. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 3, 2011

Re: [Pharo-project] Package names and illegal file names

by Igor Stasenko

On 3 February 2011 09:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > YEEEEEEEEEES > I'm fed up. > I got burnt several by $%^&* copy and paste of people > +1 .. a small snippet of code putted in right place to validate the name could save us a lot of time.. Same applied to author's name.. > On Feb 3, 2011, at 8:41 AM, Nicolas Cellier wrote: > >> I presume I am not the first to complain : >> we must enforce rules for package naming. >> >> For example >> 'Issue 3191: Â SparseLargeArray-MarcusDenker.2.mcz' >> has both a colon and an horizontal tabulation. >> >> It's screwing windows users (no possibility to update the system) >> because such filename is illegal. >> >> Nicolas >> > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 3, 2011