August 2015 - Pharo-dev - lists.pharo.org

Strange Validation with issue 15820

by Guillermo Polito

Hi, We have an issue that is platform dependent (file-related): https://pharo.fogbugz.com/f/cases/15820/Better-File-API Now, we tested with Nicolai in Windows, Mac and Linux and we had all tests green. However, the monkey does not seem to want to be green. - Would anyone have an idea of what should be disturbing the monkey? - Can people in different linuxes/unixes test the slice just to make sure we are on the right path? (that is, load the slice and run the tests in the File package). Thanks a lot, Guille

Aug. 25, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 25, 2015

[pharo-project/pharo-core] 2748ef: 50270

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2748ef632838d482014c7a033d3bbb622ef3c967 https://github.com/pharo-project/pharo-core/commit/2748ef632838d482014c7a03… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-25 (Tue, 25 Aug 2015) Changed paths: A CodeExport.package/extension/FileStream/class/writeSourceCodeFrom_baseName_isSt_.st R Files.package/FileStream.class/class/file reader services/writeSourceCodeFrom_baseName_isSt_.st M Files.package/FileStream.class/class/initialize-release/initialize.st M Files.package/ManifestFiles.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Files.package/extension/MacOSPlatform/instance/potentialLocationsOfSourcesFile.st R Files.package/extension/OSPlatform/instance/potentialLocationsOfSourcesFile.st R Files.package/extension/String/instance/asFileName.st R Files.package/extension/UnixPlatform/instance/potentialLocationsOfSourcesFile.st R Files.package/extension/Win32Platform/instance/potentialLocationsOfSourcesFile.st R Kernel.package/Character.class/class/accessing untypeable characters/euro.st R Kernel.package/Character.class/instance/accessing/digitValue2.st M Kernel.package/CompiledMethod.class/instance/literals/hasLiteralThorough_.st R Kernel.package/Object.class/instance/dependencies/release.st A Multilingual-Encodings.package/extension/Character/class/euro.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tagging/return3.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadAssign.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadBlock.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadLiteral.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadLiteralArray.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadReturn.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadSend.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadGlobal.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadIvar.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableReadTemp.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadVariableWrite.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceAssign.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceReturn.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceSend.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceVariableReadGlobal.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceVariableReadIvar.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceVariableReadTemp.st R Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceVariableWrite.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitLiteralArrayNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitLiteralNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50269.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50270.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50269.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50270.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Object Events.package/extension/Object/instance/release.st A System-Sources.package/ChangesLog.class/README.md A System-Sources.package/ChangesLog.class/class/accessing/default.st A System-Sources.package/ChangesLog.class/class/accessing/reset.st A System-Sources.package/ChangesLog.class/definition.st A System-Sources.package/ChangesLog.class/instance/accessing/recordStartupStamp.st A System-Sources.package/ChangesLog.class/instance/event-listening/logClassRemoved_.st A System-Sources.package/ChangesLog.class/instance/event-listening/logClassRenamed_.st A System-Sources.package/ChangesLog.class/instance/event-listening/logExpressionEvaluated_.st A System-Sources.package/ChangesLog.class/instance/event-listening/logMethodRemoved_.st A System-Sources.package/ChangesLog.class/instance/event-listening/registerToAnnouncements.st A System-Sources.package/ChangesLog.class/instance/logging/logChange_.st A System-Sources.package/ChangesLog.class/instance/logging/logSnapshot_andQuit_.st A System-Sources.package/ChangesLog.class/instance/private/assureStartupStampLogged.st A System-Sources.package/extension/MacOSPlatform/instance/potentialLocationsOfSourcesFile.st A System-Sources.package/extension/OSPlatform/instance/potentialLocationsOfSourcesFile.st A System-Sources.package/extension/UnixPlatform/instance/potentialLocationsOfSourcesFile.st A System-Sources.package/extension/Win32Platform/instance/potentialLocationsOfSourcesFile.st R System-Support.package/ChangesLog.class/README.md R System-Support.package/ChangesLog.class/class/accessing/default.st R System-Support.package/ChangesLog.class/class/accessing/reset.st R System-Support.package/ChangesLog.class/definition.st R System-Support.package/ChangesLog.class/instance/accessing/recordStartupStamp.st R System-Support.package/ChangesLog.class/instance/event-listening/logClassRemoved_.st R System-Support.package/ChangesLog.class/instance/event-listening/logClassRenamed_.st R System-Support.package/ChangesLog.class/instance/event-listening/logExpressionEvaluated_.st R System-Support.package/ChangesLog.class/instance/event-listening/logMethodRemoved_.st R System-Support.package/ChangesLog.class/instance/event-listening/registerToAnnouncements.st R System-Support.package/ChangesLog.class/instance/logging/logChange_.st R System-Support.package/ChangesLog.class/instance/logging/logSnapshot_andQuit_.st R System-Support.package/ChangesLog.class/instance/private/assureStartupStampLogged.st A Tool-FileList.package/extension/String/instance/asFileName.st R Traits.package/TClass.class/class/fileIn%2FOut/fileOutPool_.st Log Message: ----------- 50270 16367 #hasLiteralThorough: should not check for names of Binding https://pharo.fogbugz.com/f/cases/16367 16189 System-Sources has low-level dependents https://pharo.fogbugz.com/f/cases/16189 16375 More tests for instead links https://pharo.fogbugz.com/f/cases/16375 http://files.pharo.org/image/50/50270.zip

Aug. 25, 2015

Re: [Pharo-dev] Cleaning up Locale, LanguageEnvironment and EncodedCharSet

by Guillermo Polito

Exactly that. The only thing I wanted to say is that we cannot be sure. But I also think the change is ok for most cases and will keep us in the run. If we discover something missing we can start by adding tests later. El mar., 25 de ago. de 2015 a la(s) 4:48 p. m., Sven Van Caekenberghe < sven(a)stfx.eu> escribiÃ³: > > > On 25 Aug 2015, at 16:36, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Well, imagine the following case: > > > > - your computer is configured in a locale like japanese/greek/chinese > > AND > > - you have activated the 'System > use Locale' setting. (I was not aware > of this setting this morning ;)) > > > > Then, the image will fetch the locale from the system and instantiate a > language environment according to it. So you could end up using one of the > LanguageEnvironment subclasses that could use a leadingChar ~~ 0 friend :) > > Yes, but would that make any difference ? > I think we just don't know. > I am pretty sure it won't hurt, at all. > > > I do not know how likely is that since that setting is off by default. > > > > El mar., 25 de ago. de 2015 a la(s) 4:29 p. m., Sven Van Caekenberghe < > sven(a)stfx.eu> escribiÃ³: > > > > > On 25 Aug 2015, at 16:01, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > Hi guys, > > > > > > I was having a deep look today at Locale, LanguageEnvironment and > EncodedCharset with the objective of understanding it and see how we can > organize it better. > > > > > > As I saw, in almost all cases, it happened that the locale and > language environment are only used to get the current system's encoding. > Even, it is not that the system's encoding is obtained from the system's > configuration but guessed. Also, I saw that the usage of leadingCharacter > is very limited in the image and I'd say that most of the time we would not > be using it: we will be using unicode. > > > > > > I proposed in the issue tracker a change in three steps that cleans up > this: > > > - Cleaning Locale's API ( > https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) > > > - Fix users to make use of this new API ( > https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) > > > - Remove old unused code ( > https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code) > > > > Yes, that seems the way to go. > > > > > I know that with this change we lose temporarily the ability to use > other language environments (like greek or japanese), and thus, change to > other system encodings that are not UTF8/16/32. > > > > Why do you say that ? As far as I understand it, we would not lose > anything at all ! > > > > Leading char is a hack that does not seem to exist in other programming > languages. AFAIU, it is only needed because there are (might/used to be) a > couple (a very small number) of Unicode characters shared between 3 > languages (I believe Japanese, Korean, and maybe Chinese) where the > interpretation of the same Unicode character depends on the language. But I > am totally not sure it really is such a big deal, I could be wrong though. > > > > Still, since we do UTF-8 (and some variations, as well as many byte > encodings), I am pretty sure we support almost anything out there. > > > > > However, I believe that we should not 'guess' the system converter > from the system language but to ask the system the encoding it is using. > And this should maybe be added as a primitive (as the others already > existing in the Locale class for example). > > > > > If somebody could review these issues or has some comment on something > that I should not be aware of, I'd be grateful :). > > > > > > Guille > > > > > > >

Aug. 25, 2015

Re: [Pharo-dev] Cleaning up Locale, LanguageEnvironment and EncodedCharSet

by Sven Van Caekenberghe

> On 25 Aug 2015, at 16:36, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Well, imagine the following case: > > - your computer is configured in a locale like japanese/greek/chinese > AND > - you have activated the 'System > use Locale' setting. (I was not aware of this setting this morning ;)) > > Then, the image will fetch the locale from the system and instantiate a language environment according to it. So you could end up using one of the LanguageEnvironment subclasses that could use a leadingChar ~~ 0 friend :) Yes, but would that make any difference ? I think we just don't know. I am pretty sure it won't hurt, at all. > I do not know how likely is that since that setting is off by default. > > El mar., 25 de ago. de 2015 a la(s) 4:29 p. m., Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > On 25 Aug 2015, at 16:01, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > Hi guys, > > > > I was having a deep look today at Locale, LanguageEnvironment and EncodedCharset with the objective of understanding it and see how we can organize it better. > > > > As I saw, in almost all cases, it happened that the locale and language environment are only used to get the current system's encoding. Even, it is not that the system's encoding is obtained from the system's configuration but guessed. Also, I saw that the usage of leadingCharacter is very limited in the image and I'd say that most of the time we would not be using it: we will be using unicode. > > > > I proposed in the issue tracker a change in three steps that cleans up this: > > - Cleaning Locale's API (https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) > > - Fix users to make use of this new API (https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) > > - Remove old unused code (https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code) > > Yes, that seems the way to go. > > > I know that with this change we lose temporarily the ability to use other language environments (like greek or japanese), and thus, change to other system encodings that are not UTF8/16/32. > > Why do you say that ? As far as I understand it, we would not lose anything at all ! > > Leading char is a hack that does not seem to exist in other programming languages. AFAIU, it is only needed because there are (might/used to be) a couple (a very small number) of Unicode characters shared between 3 languages (I believe Japanese, Korean, and maybe Chinese) where the interpretation of the same Unicode character depends on the language. But I am totally not sure it really is such a big deal, I could be wrong though. > > Still, since we do UTF-8 (and some variations, as well as many byte encodings), I am pretty sure we support almost anything out there. > > > However, I believe that we should not 'guess' the system converter from the system language but to ask the system the encoding it is using. And this should maybe be added as a primitive (as the others already existing in the Locale class for example). > > > If somebody could review these issues or has some comment on something that I should not be aware of, I'd be grateful :). > > > > Guille > >

Aug. 25, 2015

Re: [Pharo-dev] Cleaning up Locale, LanguageEnvironment and EncodedCharSet

by Guillermo Polito

Well, imagine the following case: - your computer is configured in a locale like japanese/greek/chinese AND - you have activated the 'System > use Locale' setting. (I was not aware of this setting this morning ;)) Then, the image will fetch the locale from the system and instantiate a language environment according to it. So you could end up using one of the LanguageEnvironment subclasses that could use a leadingChar ~~ 0 friend :) I do not know how likely is that since that setting is off by default. El mar., 25 de ago. de 2015 a la(s) 4:29 p. m., Sven Van Caekenberghe < sven(a)stfx.eu> escribiÃ³: > > > On 25 Aug 2015, at 16:01, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Hi guys, > > > > I was having a deep look today at Locale, LanguageEnvironment and > EncodedCharset with the objective of understanding it and see how we can > organize it better. > > > > As I saw, in almost all cases, it happened that the locale and language > environment are only used to get the current system's encoding. Even, it is > not that the system's encoding is obtained from the system's configuration > but guessed. Also, I saw that the usage of leadingCharacter is very limited > in the image and I'd say that most of the time we would not be using it: we > will be using unicode. > > > > I proposed in the issue tracker a change in three steps that cleans up > this: > > - Cleaning Locale's API ( > https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) > > - Fix users to make use of this new API ( > https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) > > - Remove old unused code ( > https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code) > > Yes, that seems the way to go. > > > I know that with this change we lose temporarily the ability to use > other language environments (like greek or japanese), and thus, change to > other system encodings that are not UTF8/16/32. > > Why do you say that ? As far as I understand it, we would not lose > anything at all ! > > Leading char is a hack that does not seem to exist in other programming > languages. AFAIU, it is only needed because there are (might/used to be) a > couple (a very small number) of Unicode characters shared between 3 > languages (I believe Japanese, Korean, and maybe Chinese) where the > interpretation of the same Unicode character depends on the language. But I > am totally not sure it really is such a big deal, I could be wrong though. > > Still, since we do UTF-8 (and some variations, as well as many byte > encodings), I am pretty sure we support almost anything out there. > > > However, I believe that we should not 'guess' the system converter from > the system language but to ask the system the encoding it is using. And > this should maybe be added as a primitive (as the others already existing > in the Locale class for example). > > > If somebody could review these issues or has some comment on something > that I should not be aware of, I'd be grateful :). > > > > Guille > > >

Aug. 25, 2015

Re: [Pharo-dev] Cleaning up Locale, LanguageEnvironment and EncodedCharSet

by Sven Van Caekenberghe

> On 25 Aug 2015, at 16:01, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi guys, > > I was having a deep look today at Locale, LanguageEnvironment and EncodedCharset with the objective of understanding it and see how we can organize it better. > > As I saw, in almost all cases, it happened that the locale and language environment are only used to get the current system's encoding. Even, it is not that the system's encoding is obtained from the system's configuration but guessed. Also, I saw that the usage of leadingCharacter is very limited in the image and I'd say that most of the time we would not be using it: we will be using unicode. > > I proposed in the issue tracker a change in three steps that cleans up this: > - Cleaning Locale's API (https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) > - Fix users to make use of this new API (https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) > - Remove old unused code (https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code) Yes, that seems the way to go. > I know that with this change we lose temporarily the ability to use other language environments (like greek or japanese), and thus, change to other system encodings that are not UTF8/16/32. Why do you say that ? As far as I understand it, we would not lose anything at all ! Leading char is a hack that does not seem to exist in other programming languages. AFAIU, it is only needed because there are (might/used to be) a couple (a very small number) of Unicode characters shared between 3 languages (I believe Japanese, Korean, and maybe Chinese) where the interpretation of the same Unicode character depends on the language. But I am totally not sure it really is such a big deal, I could be wrong though. Still, since we do UTF-8 (and some variations, as well as many byte encodings), I am pretty sure we support almost anything out there. > However, I believe that we should not 'guess' the system converter from the system language but to ask the system the encoding it is using. And this should maybe be added as a primitive (as the others already existing in the Locale class for example). > If somebody could review these issues or has some comment on something that I should not be aware of, I'd be grateful :). > > Guille

Aug. 25, 2015

Cleaning up Locale, LanguageEnvironment and EncodedCharSet

by Guillermo Polito

Hi guys, I was having a deep look today at Locale, LanguageEnvironment and EncodedCharset with the objective of understanding it and see how we can organize it better. As I saw, in almost all cases, it happened that the locale and language environment are only used to get the current system's encoding. Even, it is not that the system's encoding is obtained from the system's configuration but guessed. Also, I saw that the usage of leadingCharacter is very limited in the image and I'd say that most of the time we would not be using it: we will be using unicode. I proposed in the issue tracker a change in three steps that cleans up this: - Cleaning Locale's API ( https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) - Fix users to make use of this new API ( https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) - Remove old unused code ( https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code) I know that with this change we lose temporarily the ability to use other language environments (like greek or japanese), and thus, change to other system encodings that are not UTF8/16/32. However, I believe that we should not 'guess' the system converter from the system language but to ask the system the encoding it is using. And this should maybe be added as a primitive (as the others already existing in the Locale class for example). If somebody could review these issues or has some comment on something that I should not be aware of, I'd be grateful :). Guille

Aug. 25, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 25, 2015

[pharo-project/pharo-core] c65815: 50269

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c65815c1b891362831d8c1c36f08e35f7c6d8e12 https://github.com/pharo-project/pharo-core/commit/c65815c1b891362831d8c1c3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-25 (Tue, 25 Aug 2015) Changed paths: M RecentSubmissions.package/RecentMessageList.class/instance/userinterface/open.st M Refactoring-Critics.package/RBModifiesCollectionRule.class/instance/private/modifiesTree_in_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50268.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50269.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50268.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50269.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/TemporaryVariable.class/instance/comparing/hash.st M Slot.package/TemporaryVariable.class/instance/properties/ensureProperties.st M Slot.package/TemporaryVariable.class/instance/properties/removePropertiesIfEmpty.st M Spec-Tools.package/MessageBrowser.class/instance/accessing/selectedMethod.st Log Message: ----------- 50269 16131 RBModifiesCollectionRule breaks methods AST when checking https://pharo.fogbugz.com/f/cases/16131 16363 Context menu in Recent Messages broken when empty https://pharo.fogbugz.com/f/cases/16363 16365 Make properties on TemporaryVariable persistent https://pharo.fogbugz.com/f/cases/16365 16364 Typo in Recent message browser title https://pharo.fogbugz.com/f/cases/16364 http://files.pharo.org/image/50/50269.zip

Aug. 25, 2015