March 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Capitalized

by John Brant

On 03/15/2017 05:33 AM, Torsten Bergmann wrote: > According to https://en.wikipedia.org/wiki/Capitalization > > to "capitalize" is writing a word with its first letter as a capital letter (upper-case letter) > AND THE REMAINING LETTERS IN LOWER CASE writing systems. > > So > > 'SOMETHING' capitalized > > currently returns "SOMETHING" in Pharo but should return "Something" according to the definition to end up with lowercase. > If we fix this I guess we would also align Pharo with other languages, like C# for example [1]. That wouldn't be what I would expect. Here's what dictionary.com has for capitalize: 1. to write or print in capital letters letters or with an initial capital letter That definition doesn't say what happens with the rest of the letters. As for C#, isn't that someone's extension method for String and not a Microsoft method? I don't see that method on Microsoft's current String class documentation: https://msdn.microsoft.com/en-us/library/system.string(v=vs.110).aspx Also, the Uncapitalize method is inconsistent with the Capitalize method. The Uncapitalize method changes only the first character and all other characters are unchanged. However, the Capitalize method can change all characters. Finally, Dolphin Smalltalk has an implementation that is similar to Pharo's: https://github.com/dolphinsmalltalk/Dolphin/blob/master/Core/Object%20Arts/… John Brant

March 15, 2017

Re: [Pharo-dev] Capitalized

by Peter Uhnak

Maybe for next Pharo version? As this is a breaking change, which you cannot just deprecate. Also then there would need to be another method that provides the current behavior. Peter On Wed, Mar 15, 2017 at 12:16:44PM +0000, Henrik Nergaard wrote: > >to "capitalize" is writing a word with its first letter. > > The Smalltalk String is not neccessarily just a word, it could be something else so the current implementation makes no assumptions of what the string is. > > --------------------------------------------------------------------------------------------- > > | newClass | > > newClass := Object subclass: #AbcSomeClass > instanceVariableNames: 'errorCodeName referencePosition instanceVariable'. > newClass instanceVariableNamesDo: [ :aString | | code | > code := String streamContents: [ :aStream | | prefix cap | > prefix := aString first isVowel ifTrue: ['an'] ifFalse: ['a']. > cap := aString capitalized. > aStream > << aString; << ':'; space; << prefix; << cap; > cr; cr; tab; > << aString; << ' := '; << prefix; << cap. > ]. > newClass compile: code classified: 'accessing' > ]. > > newClass browse > -------------------------------------------------------------------------------------------- > > > >Should we fix this? Do not know about any side effects... > > I think it would be better and more clear to then implement a new method called something like #onlyCapitalized that removes all other uppercase letters. > > > Best regards, > > Henrik > > > ________________________________ > Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Torsten Bergmann <astares(a)gmx.de> > Sendt: 15. mars 2017 11:33:35 > Til: Pharo Development List > Emne: [Pharo-dev] Capitalized > > According to https://en.wikipedia.org/wiki/Capitalization > > to "capitalize" is writing a word with its first letter as a capital letter (upper-case letter) > AND THE REMAINING LETTERS IN LOWER CASE writing systems. > > So > > 'SOMETHING' capitalized > > currently returns "SOMETHING" in Pharo but should return "Something" according to the definition to end up with lowercase. > If we fix this I guess we would also align Pharo with other languages, like C# for example [1]. > > Could be easily changed by replacing "copy" with "asLowercase" in #capitalized: > > capitalized > "Return a copy with the first letter capitalized" > | cap | > self isEmpty ifTrue: [ ^self copy ]. > cap := self asLowercase. > cap at: 1 put: (cap at: 1) asUppercase. > ^ cap > > Should we fix this? Do not know about any side effects... > > > Note: a) Squeak has the same issue > b) it fits for #uncapitalized, see [2] > c) Dont know about ANSI standard or any other ST dialect > > Thx > T. > > > [1] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Capital… > [2] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Uncapit… >

March 15, 2017

[pharo-project/pharo-core] f35d0c: 60442

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f35d0c707461ac1263574710cb05737da37ca5dd https://github.com/pharo-project/pharo-core/commit/f35d0c707461ac1263574710… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-15 (Wed, 15 Mar 2017) Changed paths: M Athens-Cairo.package/CairoLibrary.class/instance/accessing platform/unixModuleName.st R Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/utils/importIcons.st R Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/class/private/importIcons_fromFolder_inClass_category_.st R Polymorph-Widgets.package/Pharo3DarkTheme.class/class/private/importIcons_fromFolder_inClass_category_.st R Polymorph-Widgets.package/Pharo3Theme.class/class/private/importIcons_fromFolder_inClass_category_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60441.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60442.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60441.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60442.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Zinc-FileSystem.package/ZnMonticelloServerDelegate.class/instance/private/repositoryListing.st Log Message: ----------- 60442 19838 ZnMonticelloServerDelegate>>#repositoryListing sends self self https://pharo.fogbugz.com/f/cases/19838 19668 importIcons:fromFolder:inClass:category: sends unimplemented methods https://pharo.fogbugz.com/f/cases/19668 19833 CairoLibrary unix module location assumptions too restrictive https://pharo.fogbugz.com/f/cases/19833 http://files.pharo.org/image/60/60442.zip

March 15, 2017

[pharo-project/pharo-core]

by GitHub

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

March 15, 2017

Re: [Pharo-dev] Missing Zip64 support

by Esteban Lorenzano

Hi, yes, Iceberg will solve this problem by not having it, but it would be nice to be able to unzip bigger files from Pharo too (ok, maybe not a priority, but it would be cool anyway :P) Esteban > On 15 Mar 2017, at 13:07, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > To clone the repository from Pharo we can use Iceberg: > > IceRepositoryCreator new > remote: (IceRemote url: 'https://github.com/guillep/pharo-core.git' <https://github.com/guillep/pharo-core.git'>); > location: ('pharo-core' asFileReference ensureCreateDirectory); > createRepository. > > 2017-03-15 11:31 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: > Hi Pavel, > > Which means command like these: > > cd pharo; mkdir filetree; cd filetree; wget -O - https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev <https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev> | tar xz --strip-components=1 > > ./pharo-cli pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'FileTree\'\; repository: \'filetree:///`pwd`/pharo/filetree/repository\'\; load: \'Git\'. > > recovering the tarball can be a lot faster than doing a local clone, and FileTree is not interested in the git history anyway... > > Thierry > > > 2017-03-15 11:18 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: > Hi, > > our current Compression package does not support Zip64 which is limiting us in usage of Metacello together with Git. When we use the Metacello for installing of a baseline like: > > Metacello new > baseline: 'IDE'; > repository: 'github://guillep/pharo-core'; > load. > > then the Metacello downloads the corresponding archive from Github. However the standard Zip archives have count limit of 65535 members but the pharo-core repository and some others contain much more than this (pharo-core has 125021 files). The Zip64 extension is used for them during compression which we cannot read now. > > So if you will see Error: bad signature 16r... at position ..., then it has this reason. The workaround for now is to load projects from a local clone of such big repositories. > > Cheers, > -- Pavel > >

March 15, 2017

ZnInvalidUTF8 on response from squeaksource

by Patrick R.

Hi everyone, I have been working on bringing http://squeaksource.com/ical/ up to speed for Squeak and wanted to make sure that it also works for Pharo. Therefore, I have created a travis build job for Squeak and Pharo (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which pulls the source from squeaksource.com. Now the issue is that loading the package in Pharo fails with a GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this might be the result of the squeaksource page delivering the page as iso-8859-1 as it contains special characters. Any ideas on how to get this to work? I do not have access to the ical repository description and I would liek to avoid mirroring the whole repository on GitHub. Thanks and bests Patrick -- View this message in context: http://forum.world.st/ZnInvalidUTF8-on-response-from-squeaksource-tp4938787… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 15, 2017

Re: [Pharo-dev] Capitalized

by Henrik Nergaard

>to "capitalize" is writing a word with its first letter. The Smalltalk String is not neccessarily just a word, it could be something else so the current implementation makes no assumptions of what the string is. --------------------------------------------------------------------------------------------- | newClass | newClass := Object subclass: #AbcSomeClass instanceVariableNames: 'errorCodeName referencePosition instanceVariable'. newClass instanceVariableNamesDo: [ :aString | | code | code := String streamContents: [ :aStream | | prefix cap | prefix := aString first isVowel ifTrue: ['an'] ifFalse: ['a']. cap := aString capitalized. aStream << aString; << ':'; space; << prefix; << cap; cr; cr; tab; << aString; << ' := '; << prefix; << cap. ]. newClass compile: code classified: 'accessing' ]. newClass browse -------------------------------------------------------------------------------------------- >Should we fix this? Do not know about any side effects... I think it would be better and more clear to then implement a new method called something like #onlyCapitalized that removes all other uppercase letters. Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Torsten Bergmann <astares(a)gmx.de> Sendt: 15. mars 2017 11:33:35 Til: Pharo Development List Emne: [Pharo-dev] Capitalized According to https://en.wikipedia.org/wiki/Capitalization to "capitalize" is writing a word with its first letter as a capital letter (upper-case letter) AND THE REMAINING LETTERS IN LOWER CASE writing systems. So 'SOMETHING' capitalized currently returns "SOMETHING" in Pharo but should return "Something" according to the definition to end up with lowercase. If we fix this I guess we would also align Pharo with other languages, like C# for example [1]. Could be easily changed by replacing "copy" with "asLowercase" in #capitalized: capitalized "Return a copy with the first letter capitalized" | cap | self isEmpty ifTrue: [ ^self copy ]. cap := self asLowercase. cap at: 1 put: (cap at: 1) asUppercase. ^ cap Should we fix this? Do not know about any side effects... Note: a) Squeak has the same issue b) it fits for #uncapitalized, see [2] c) Dont know about ANSI standard or any other ST dialect Thx T. [1] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Capital… [2] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Uncapit…

March 15, 2017

Re: [Pharo-dev] Missing Zip64 support

by Pavel Krivanek

To clone the repository from Pharo we can use Iceberg: IceRepositoryCreator new remote: (IceRemote url: 'https://github.com/guillep/pharo-core.git'); location: ('pharo-core' asFileReference ensureCreateDirectory); createRepository. 2017-03-15 11:31 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Pavel, > > Which means command like these: > > cd pharo; mkdir filetree; cd filetree; wget -O - > https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev | > tar xz --strip-components=1 > > ./pharo-cli pharo/Pharo.image --no-default-preferences eval --save > Metacello new baseline: \'FileTree\'\; repository: > \'filetree:///`pwd`/pharo/filetree/repository\'\; load: \'Git\'. > > recovering the tarball can be a lot faster than doing a local clone, and > FileTree is not interested in the git history anyway... > > Thierry > > > 2017-03-15 11:18 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Hi, >> >> our current Compression package does not support Zip64 which is limiting >> us in usage of Metacello together with Git. When we use the Metacello for >> installing of a baseline like: >> >> Metacello new >> baseline: 'IDE'; >> repository: 'github://guillep/pharo-core'; >> load. >> >> then the Metacello downloads the corresponding archive from Github. >> However the standard Zip archives have count limit of 65535 members but the >> pharo-core repository and some others contain much more than this >> (pharo-core has 125021 files). The Zip64 extension is used for them during >> compression which we cannot read now. >> >> So if you will see Error: bad signature 16r... at position ..., then it >> has this reason. The workaround for now is to load projects from a local >> clone of such big repositories. >> >> Cheers, >> -- Pavel >> > >

March 15, 2017

Capitalized

by Torsten Bergmann

According to https://en.wikipedia.org/wiki/Capitalization to "capitalize" is writing a word with its first letter as a capital letter (upper-case letter) AND THE REMAINING LETTERS IN LOWER CASE writing systems. So 'SOMETHING' capitalized currently returns "SOMETHING" in Pharo but should return "Something" according to the definition to end up with lowercase. If we fix this I guess we would also align Pharo with other languages, like C# for example [1]. Could be easily changed by replacing "copy" with "asLowercase" in #capitalized: capitalized "Return a copy with the first letter capitalized" | cap | self isEmpty ifTrue: [ ^self copy ]. cap := self asLowercase. cap at: 1 put: (cap at: 1) asUppercase. ^ cap Should we fix this? Do not know about any side effects... Note: a) Squeak has the same issue b) it fits for #uncapitalized, see [2] c) Dont know about ANSI standard or any other ST dialect Thx T. [1] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Capital… [2] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/Uncapit…

March 15, 2017

Re: [Pharo-dev] Missing Zip64 support

by Thierry Goubier

Hi Pavel, Which means command like these: cd pharo; mkdir filetree; cd filetree; wget -O - https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev | tar xz --strip-components=1 ./pharo-cli pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'FileTree\'\; repository: \'filetree:///`pwd`/pharo/filetree/repository\'\; load: \'Git\'. recovering the tarball can be a lot faster than doing a local clone, and FileTree is not interested in the git history anyway... Thierry 2017-03-15 11:18 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > our current Compression package does not support Zip64 which is limiting > us in usage of Metacello together with Git. When we use the Metacello for > installing of a baseline like: > > Metacello new > baseline: 'IDE'; > repository: 'github://guillep/pharo-core'; > load. > > then the Metacello downloads the corresponding archive from Github. > However the standard Zip archives have count limit of 65535 members but the > pharo-core repository and some others contain much more than this > (pharo-core has 125021 files). The Zip64 extension is used for them during > compression which we cannot read now. > > So if you will see Error: bad signature 16r... at position ..., then it > has this reason. The workaround for now is to load projects from a local > clone of such big repositories. > > Cheers, > -- Pavel >

March 15, 2017