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

[Pharo-project] [update 1.4] #14332

by StÃ©phane Ducasse

14332 ----- - Issue 5283: Little refactor in PluggaleListMorph. Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5283 - Issue 5298: Infinite Loop in MenuRegistration.Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5298 - Issue 5288: Introduce a new method in the searching method of PluggableListMorph. Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5288

Feb. 15, 2012

[Pharo-project] moved repos to gemstone

by Camillo Bruni

If the corresponding project admins would agree it would be cool to move the development to ss3 on gemstone of the following projects I ported so far: - Citezen http://ss3.gemstone.com/ss/citezen - FSFilesystem http://ss3.gemstone.com/ss/fs - FSGit http://ss3.gemstone.com/ss/fs-git - PetitMarkdown http://www.squeaksource.com/PetitMarkdown - PharoRB http://ss3.gemstone.com/ss/rb-pharo - Refactoring Engine http://ss3.gemstone.com/ss/rb - Soup http://ss3.gemstone.com/ss/soup - XMLSupport http://ss3.gemstone.com/ss/xmlsupport I tried to add people from the old projects as admins Please let me know

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by Camillo Bruni

makes more sense to me On 2012-02-15, at 15:29, Esteban Lorenzano wrote: > hi, > > FSPath>>#withExtension: is ignoring adding extension if extension is equal to end of basename. > > For example, if I want to produce: > > (FSFilesystem disk workingDirectory / 'Host') withExtension: 'st'. > > I should receive: > > /path/to/Host.st > > but I actually receive: > > /path/to/Host > > that can be fixed replacing > > FSPath>>#withExtension: extension > | basename name | > basename := self basename. > ^ (basename endsWith: extension) > ifTrue: [ self ] > ifFalse: > [name := basename copyUpToLast: self extensionDelimiter. > self withName: name extension: extension] > > with: > > FSPath>>#withExtension: extension > | basename name | > basename := self basename. > ^ (basename endsWith: '.', extension) > ifTrue: [ self ] > ifFalse: > [name := basename copyUpToLast: self extensionDelimiter. > self withName: name extension: extension] > > but I don't know if that would be a good solution :) > > best, > Esteban

Feb. 15, 2012

[Pharo-project] FSPath withExtension: bug

by Esteban Lorenzano

hi, FSPath>>#withExtension: is ignoring adding extension if extension is equal to end of basename. For example, if I want to produce: (FSFilesystem disk workingDirectory / 'Host') withExtension: 'st'. I should receive: /path/to/Host.st but I actually receive: /path/to/Host that can be fixed replacing FSPath>>#withExtension: extension | basename name | basename := self basename. ^ (basename endsWith: extension) ifTrue: [ self ] ifFalse: [name := basename copyUpToLast: self extensionDelimiter. self withName: name extension: extension] with: FSPath>>#withExtension: extension | basename name | basename := self basename. ^ (basename endsWith: '.', extension) ifTrue: [ self ] ifFalse: [name := basename copyUpToLast: self extensionDelimiter. self withName: name extension: extension] but I don't know if that would be a good solution :) best, Esteban

Feb. 15, 2012

Re: [Pharo-project] faster process to move to gemstone

by Sven Van Caekenberghe

Small typo, make that: | repositoryUrl files | repositoryUrl := 'http://www.squeaksource.com/Citezen/'. files := (MCHttpRepository new parseFileNamesFromStream: (ZnClient new get: repositoryUrl; entity) readStream) select: [ :each | ZnMonticelloServerDelegate new isValidMczName: each ]. files. ZnClient new url: repositoryUrl; addPath: files first; get; entity. (Not that you wouldn't have been able to fix it, but I like good out of the box experience) On 15 Feb 2012, at 13:36, Sven Van Caekenberghe wrote: > Hey Camillo, > > On 15 Feb 2012, at 13:02, Camillo Bruni wrote: > >> yesterday I did my daily batch conversion to gemstone and I came up with a slightly faster process. >> If you use gofer I fear that all the monticello versions are completely parsed before being saved / uploaded. >> >> I tried to avoid this using wget to download all the versions and then script the upload >> >> ========================================================================== >> # bash, takes around 1min vs 10mins with gofer >> wget --mirror --page-requisites http://www.squeaksource.com/Citezen/ >> >> # pharo >> f := FSFilesystem disk workingDirectory / 'www.squeaksource.com' / 'Citezen'. >> files := f glob: [ :f| f basename endsWith: '.mcz']. >> >> files do: [ :file ||entity stream| >> stream := file readStream. >> (entity := ZnStreamingEntity type: ZnMimeType applicationOctetStream) >> stream: stream; >> contentLength: stream size. >> Transcript show: file; cr. >> "upload the version to gemstone" >> ZnClient new >> systemPolicy; >> beOneShot; >> signalProgress: true; >> ifFail: [ :exception | Transcript show: file basename; show: ' '; print: exception ]; >> username: 'XXX' password: 'XXX'; >> entity: entity; >> url: ( 'http://ss3.gemstone.com/ss/citezen/', file basename); >> put ] >> displayingProgress: 'Uploading mzcs' >> ========================================================================== >> >> best >> cami > > Cool stuff, beautiful script ! > > I don't know enough about the internals of Gofer and/or Monticello, but doing what the wget does is easy in Smalltalk. > > repositoryUrl := 'http://www.squeaksource.com/ZincHTTPComponents/'. > files := (MCHttpRepository new > parseFileNamesFromStream: (ZnClient new get: repositoryUrl) entity readStream) > select: [ :each | ZnMonticelloServerDelegate new isValidMczName: each ]. > files do: [ :each | | mcz | > Transcript cr; show: each. > mcz := (ZnClient new get: 'http://www.squeaksource.com/ZincHTTPComponents/', each) entity. > "â¦" ]. > > You can use the mcz entity directly as an argument to the next put. > > What do you think ? > > Let me know how fast is goes. > > Sven > > > > > >

Feb. 15, 2012

Re: [Pharo-project] faster process to move to gemstone

by Camillo Bruni

On 2012-02-15, at 13:36, Sven Van Caekenberghe wrote: > Hey Camillo, > > On 15 Feb 2012, at 13:02, Camillo Bruni wrote: > >> yesterday I did my daily batch conversion to gemstone and I came up with a slightly faster process. >> If you use gofer I fear that all the monticello versions are completely parsed before being saved / uploaded. >> >> I tried to avoid this using wget to download all the versions and then script the upload >> >> ========================================================================== >> # bash, takes around 1min vs 10mins with gofer >> wget --mirror --page-requisites http://www.squeaksource.com/Citezen/ >> >> # pharo >> f := FSFilesystem disk workingDirectory / 'www.squeaksource.com' / 'Citezen'. >> files := f glob: [ :f| f basename endsWith: '.mcz']. >> >> files do: [ :file ||entity stream| >> stream := file readStream. >> (entity := ZnStreamingEntity type: ZnMimeType applicationOctetStream) >> stream: stream; >> contentLength: stream size. >> Transcript show: file; cr. >> "upload the version to gemstone" >> ZnClient new >> systemPolicy; >> beOneShot; >> signalProgress: true; >> ifFail: [ :exception | Transcript show: file basename; show: ' '; print: exception ]; >> username: 'XXX' password: 'XXX'; >> entity: entity; >> url: ( 'http://ss3.gemstone.com/ss/citezen/', file basename); >> put ] >> displayingProgress: 'Uploading mzcs' >> ========================================================================== >> >> best >> cami > > Cool stuff, beautiful script ! > > I don't know enough about the internals of Gofer and/or Monticello, but doing what the wget does is easy in Smalltalk. > > repositoryUrl := 'http://www.squeaksource.com/ZincHTTPComponents/'. > files := (MCHttpRepository new > parseFileNamesFromStream: (ZnClient new get: repositoryUrl) entity readStream) > select: [ :each | ZnMonticelloServerDelegate new isValidMczName: each ]. > files do: [ :each | | mcz | > Transcript cr; show: each. > mcz := (ZnClient new get: 'http://www.squeaksource.com/ZincHTTPComponents/', each) entity. > "â¦" ]. > > You can use the mcz entity directly as an argument to the next put. > > What do you think ? ah well if that works even better :D I am lazy :D and I don't have to think when using wget :P > Let me know how fast is goes. > > Sven > > > > > >

Feb. 15, 2012

Re: [Pharo-project] [update 1.3] #13321

by Lukas Renggli

Thank you for working on Pharo 1.3 :-) On 15 February 2012 14:16, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 13321 > ----- > > Issue 5228: Â Â MorphTreeMorph hide last element when horizontal scrollbar is shown > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5228 > Issue 4840: Â Â Schedule>>between:and:do can iterate over the wrong dates. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4840 > > > > -- > Marcus Denker -- http://marcusdenker.de > > -- Lukas Renggli www.lukas-renggli.ch

Feb. 15, 2012

[Pharo-project] [update 1.3] #13321

by Marcus Denker

13321 ----- Issue 5228: MorphTreeMorph hide last element when horizontal scrollbar is shown http://code.google.com/p/pharo/issues/detail?id=5228 Issue 4840: Schedule>>between:and:do can iterate over the wrong dates. http://code.google.com/p/pharo/issues/detail?id=4840 -- Marcus Denker -- http://marcusdenker.de

Feb. 15, 2012

Re: [Pharo-project] Are Objects really hard?

by Toon Verwaest

Reminds me of http://www.infoq.com/interviews/foote-oop-code On 02/11/2012 01:21 PM, Janko MivÅ¡ek wrote: > Hi guys, > > Again one interesting topic for this weekend to discuss. David Nolen, a > Lisp and JavaScript guy posted in his blog an article titled Illiterate > Programming [1] where he said: > > "...Yet I think Smalltalk still fundamentally failed (remember this is a > programming language originally designed to scale from children to > adults) because *Objects are really hard* and no-one really understands > to this day how to do them right...." > > He links to Alan Kay post [2] back in 1998 where he talks about problems > with inheritance: > > "Here are a few problems in the naive inheritance systems we use today: > confusions of Taxonomy and Parentage, of Specialization and Refinement, > of Parts and Wholes, of Semantics and Pragmatics..." > > Let we concentrate on broader "Objects are really hard and no-one really > understands to this day how to do them right" claim and not merely > inheritance, please. > > Best regards > Janko > > [1] http://dosync.posterous.com/illiterate-programming > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.ht… >

Feb. 15, 2012

Re: [Pharo-project] [squeak-dev] Are Objects really hard?

by H. Hirzel

On 2/11/12, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Hi guys, > > Again one interesting topic for this weekend to discuss. David Nolen, a > Lisp and JavaScript guy posted in his blog an article titled Illiterate > Programming [1] where he said: > > "...Yet I think Smalltalk still fundamentally failed (remember this is a > programming language originally designed to scale from children to > adults) because *Objects are really hard* and no-one really understands > to this day how to do them right...." > > He links to Alan Kay post [2] back in 1998 where he talks about problems > with inheritance: > > "Here are a few problems in the naive inheritance systems we use today: > confusions of Taxonomy and Parentage, of Specialization and Refinement, > of Parts and Wholes, of Semantics and Pragmatics..." > > Let we concentrate on broader "Objects are really hard and no-one really > understands to this day how to do them right" claim and not merely > inheritance, please. > > Best regards > Janko > > [1] http://dosync.posterous.com/illiterate-programming > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.ht… > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > Interestingly on the cited page http://dosync.posterous.com/illiterate-programming we read "There's nothing more powerful in aiding readability than a small core set of concepts. In this sense I think Smalltalk continues to be one of the few languages to get anywhere near LISP. " --Hannes

Feb. 15, 2012