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

Re: [Pharo-project] [update 1.2] #12327

by laurent laffont

On Mon, Jan 31, 2011 at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jan 30, 2011, at 10:47 PM, StÃ©phane Ducasse wrote: > > > republished. > > Now waiting for hudson to see. > > > > I like automatic builds and tests! > > I think it brings an improvement equal (or even larger) then using > bug-tracking vs. not using it. > > And if now somebody says: "Everyone uses a bug tracker": No, Squeak did not > for many, many years. And when > it did, not many people looked at it... amazing now in retrospect. > > We will say the same about continuous integration soon, especially when it > encompasses > everything: VM build from source, *that* vm used to run tests, the > resulting image and vm used to build the > artefact people download automatically, every time a commit happens. > > And that for all supported plattforms, of course. > CI is a big step forward. I can download last built and work instantaneously on the current failing tests. As a free-time contributor this is a HUGE gain of time. It seems the current bottleneck in the process is patch integration on external packages (like OB). May be we can have a PharoPatchQueue repository so we can integrate patch that have passed QA but still not integrated in external packages. Then I hope we'll see Lint Checks, list of non-commented classes, test coverage, automatic API doc :) Laurent. > > >>> Marcus I published the other sounds fixes in the sound packages. > >>> Now I do not know how the dev image is specified. May be the script > should be changed to load the new packages versions I published. > >>> Do you know where is this script? > > > It uses the ConfigurationOfPharo > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 31, 2011

Re: [Pharo-project] [update 1.2] #12327

by Marcus Denker

On Jan 31, 2011, at 9:09 AM, StÃ©phane Ducasse wrote: >> >> >>>>> Marcus I published the other sounds fixes in the sound packages. >>>>> Now I do not know how the dev image is specified. May be the script should be changed to load the new packages versions I published. >>>>> Do you know where is this script? >> >> >> It uses the ConfigurationOfPharo >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfPharo'; >> load. > > Ok I will have a look at it during a break of proposal writing > We need to check how the 1.1 is build... I fear it loads the same config as 1.2 right now, which it should not. And the same for 1.3: it needs it's own config. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 31, 2011

Re: [Pharo-project] [update 1.2] #12327

by StÃ©phane Ducasse

> > >>>> Marcus I published the other sounds fixes in the sound packages. >>>> Now I do not know how the dev image is specified. May be the script should be changed to load the new packages versions I published. >>>> Do you know where is this script? > > > It uses the ConfigurationOfPharo > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. Ok I will have a look at it during a break of proposal writing Stef

Jan. 31, 2011

Re: [Pharo-project] [update 1.2] #12327

by Marcus Denker

On Jan 30, 2011, at 10:47 PM, StÃ©phane Ducasse wrote: > republished. > Now waiting for hudson to see. > I like automatic builds and tests! I think it brings an improvement equal (or even larger) then using bug-tracking vs. not using it. And if now somebody says: "Everyone uses a bug tracker": No, Squeak did not for many, many years. And when it did, not many people looked at it... amazing now in retrospect. We will say the same about continuous integration soon, especially when it encompasses everything: VM build from source, *that* vm used to run tests, the resulting image and vm used to build the artefact people download automatically, every time a commit happens. And that for all supported plattforms, of course. >>> Marcus I published the other sounds fixes in the sound packages. >>> Now I do not know how the dev image is specified. May be the script should be changed to load the new packages versions I published. >>> Do you know where is this script? It uses the ConfigurationOfPharo Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 31, 2011

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by StÃ©phane Ducasse

> > The answer of 'Smalltalk tools' should be a tool registry instance. > > The tool registry is a system-wide object where packages can register > their tools. > I don't remember all of the details, but the idea, when i implemented > it was following: > > - you registering your tool(s) by sending: > > Smalltalk tools addTool: myTool verb: #myTool would be good to have addTool: myTool named: #myTool kind: #codebrowser so that we can avoid to have one subclass per kind. Stef

Jan. 31, 2011

[Pharo-project] See me @ Smalltalk Solutions 2011 ...

by James Ladd

Hi All, If you happen to come along to Smalltalk Solutions 2011 in Vegas, please try to say Hello to me. I'll be presenting on Redline Smalltalk and I'd really like to meet people from this list. Rgs, James.

Jan. 31, 2011

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by Tudor Girba

Thanks for the explanations, Igor. I like the direction. Cheers, Doru On 31 Jan 2011, at 03:01, Igor Stasenko wrote: > On 30 January 2011 20:30, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I am not sure what is the current status in this area. Could anyone provide an idea of what is the desired solution? >> > > The idea is to get rid of ToolSet references and replace all patterns like > > ToolSet default foo > > with > > Smalltalk tools foo > > or even more extreme, leave only a message send and get rid of using > globals, because it is early binding: > > self toolset foo > > where #toolset implemented in Object with > ^ Smalltalt tools. > > The answer of 'Smalltalk tools' should be a tool registry instance. > > The tool registry is a system-wide object where packages can register > their tools. > I don't remember all of the details, but the idea, when i implemented > it was following: > > - you registering your tool(s) by sending: > > Smalltalk tools addTool: myTool verb: #myTool > > and then you can send messages to registry directly using #myTool selector: > > Smalltalk tools myTool > > So, there will be no hardcoded set of tools in a system and therefore > no need for having a class, like ToolSet, > which implements a protocol for 'standard' toolset. > I imagine in stripped down images, some tools can be non-existing, but > some still could be there. > Making tools pluggable will improve modularity. > > >> Cheers, >> Doru >> >> >> On 28 Jan 2011, at 19:35, Igor Stasenko wrote: >> >>> On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>>> yes, check the archives. I opened tickes for that. and I sent several mails. >>>> Seems no-one has time to do it. >>>> >>> we discussed that today. >>> probably i will take care about it for 1.3.. not sure how soon it will >>> be but i will :) >>> >>>> http://code.google.com/p/pharo/issues/detail?id=1915 >>>> >>>> On Fri, Jan 28, 2011 at 10:44 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> Because it would be good that it uses a registration mechanism. >>>>> Hardcoding the classes of the tools is not optimal for example for the new >>>>> Finder. >>>>> >>>>> Stef >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "What we can governs what we wish."

Jan. 31, 2011

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by Igor Stasenko

On 30 January 2011 20:30, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I am not sure what is the current status in this area. Could anyone provide an idea of what is the desired solution? > The idea is to get rid of ToolSet references and replace all patterns like ToolSet default foo with Smalltalk tools foo or even more extreme, leave only a message send and get rid of using globals, because it is early binding: self toolset foo where #toolset implemented in Object with ^ Smalltalt tools. The answer of 'Smalltalk tools' should be a tool registry instance. The tool registry is a system-wide object where packages can register their tools. I don't remember all of the details, but the idea, when i implemented it was following: - you registering your tool(s) by sending: Smalltalk tools addTool: myTool verb: #myTool and then you can send messages to registry directly using #myTool selector: Smalltalk tools myTool So, there will be no hardcoded set of tools in a system and therefore no need for having a class, like ToolSet, which implements a protocol for 'standard' toolset. I imagine in stripped down images, some tools can be non-existing, but some still could be there. Making tools pluggable will improve modularity. > Cheers, > Doru > > > On 28 Jan 2011, at 19:35, Igor Stasenko wrote: > >> On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> yes, check the archives. I opened tickes for that. and I sent several mails. >>> Seems no-one has time to do it. >>> >> we discussed that today. >> probably i will take care about it for 1.3.. not sure how soon it will >> be but i will :) >> >>> http://code.google.com/p/pharo/issues/detail?id=1915 >>> >>> On Fri, Jan 28, 2011 at 10:44 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> Because it would be good that it uses a registration mechanism. >>>> Hardcoding the classes of the tools is not optimal for example for the new >>>> Finder. >>>> >>>> Stef >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > -- Best regards, Igor Stasenko AKA sig.

Jan. 31, 2011

Re: [Pharo-project] [update 1.2] #12327

by StÃ©phane Ducasse

republished. Now waiting for hudson to see. >> Marcus I published the other sounds fixes in the sound packages. >> Now I do not know how the dev image is specified. May be the script should be changed to load the new packages versions I published. >> Do you know where is this script? Stef

Jan. 30, 2011

Re: [Pharo-project] [update 1.2] #12327

by StÃ©phane Ducasse

I rollbacked the changes since I got a dependency on archiveViewer (no idea why but I'm checking). On Jan 30, 2011, at 9:58 PM, StÃ©phane Ducasse wrote: > 12327 > ----- > > - Issue 3482: InterimSoundMorph references to SketchMorph. Fixing the SoundService registration + making sure that it delegates to the registered sound system when available. After the Sound packages can be updated. > > Marcus I published the other sounds fixes in the sound packages. > Now I do not know how the dev image is specified. May be the script should be changed to load the new packages versions I published. > Do you know where is this script? > > Stef

Jan. 30, 2011