- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: Object new foo

by Eliot Miranda

Hi Vincent, On Sun, Aug 23, 2015 at 9:53 AM, Vincent BLONDEAU < vincent.blondeau(a)polytech-lille.net> wrote: > Hi Eliot, > > > > Thanks for your help. > > The problem has been resolved! > > In fact a class was removed or renamed in Pharo, and the Moose debugger > calls it just before the opening. > > So it created an infinite loop, because the class wasnât understood by the > system, so it opened another debugger, etcâ¦. > > > > Do you think something can be made to not break the image and so to break > this infinite loop? > It may make sense to set a flag early in Debugger opening, and test this flag immediately before it is set to check for recursion. But the issue is what to do in that case. One can't open a debugger, because the attempt is failing. So one can only fall back on some more primitive error handler. Note that the flag should be specific to the thread of control, which may be difficult if the Debugger runs in a separate process. One doesn't want to prevent multiple debuggers, only stop recursion within a single error. > A solution may to open either another registered debugger, or the > emergency debugger? > Yes, the emergency debugger. > > > I can create an image with the problem if needed. > > > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part > de* Eliot Miranda > *EnvoyÃ© :* jeudi 20 aoÃ»t 2015 22:13 > *Ã :* Pharo Development List > *Cc :* Moose-related development; Squeak Virtual Machine Development > Discussion > *Objet :* Re: [Pharo-dev] [Moose-dev] Re: Object new foo > > > > Hi Vincent, > > > > does the image lock up when you execute Exception signal? The two > functions you see looping are part of the implementation of primitives 195 > & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) > & terminateTo: (primitiveTerminateTo). So if the image locks up the > question is, is what is creating a circular structure of contexts, the VM > or the image? I am willing to take a look at an image that contains the > case. If you can create an image which enters the lop on start-up without > my having to do anything I'm happy to take a look. > > > > On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > Hi, > > > > On last Moose image, I debugged the VM and executed âException signalâ. > > I paused the VM and saw that 2 methods are looping together in > gcc3x-cointerp.c: > > static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt > primitive, sqInt senderContext, sqInt homeContext); > > static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, > char *startFP, sqInt homeContext); > > > > The image is looping only when the debugger is launch on Error (not by > launching it by the script below). > > > > Maybe someone on the Pharo mailing list knows what is happening? > > > > Thanks in advance, > > > > Cheers, > > Vincent > > > > *De :* moose-dev-bounces(a)iam.unibe.ch [mailto: > moose-dev-bounces(a)iam.unibe.ch] *De la part de* Andrei Chis > *EnvoyÃ© :* mardi 18 aoÃ»t 2015 10:53 > *Ã :* Moose-related development > *Objet :* [Moose-dev] Re: Object new foo > > > > Hi Vincent, > > > > You example will also kill the Pharo debugger :) > > The issue is that you pass 'Processor activeProcess' which gets terminated > when you close the debugger. > > When you open the debugger you need to make sure the process > > on which it is opened is suspended and can get terminated with no problem. > > > > A different way to redo the example would be: > > > > context := Context > > sender: nil > > receiver: {1 . 2 . 2} > > method: (OrderedCollection>>#add:) > > arguments: #(10). > > process := Process > > forContext: context > > priority: Processor userInterruptPriority. > > GTGenericStackDebugger openOn: (DebugSession process: process context: > context). > > > > There is a basic test for opening the debugger > in GTGenericStackDebuggerSmokeTest but more could help. > > > > Cheers, > > Andrei > > > > > > On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > Indeed. Maybe some tests has to be added.. > > > > But for now, it seems that the debugger is crashing the imageâ¦ Not just by > launching it: > > GTGenericStackDebugger openOn: (DebugSession process: Processor > activeProcess context: (Context > > sender: nil > > receiver: {1 . 2 . 2} > > method: (OrderedCollection>>#add: ) > > arguments: #(10))) > > > > But when an exception is thrown, its seems that we fall into an infinite > loop around the primitive 199. Maybe the context is not well set? > > > > Cheers, > > Vincent > > > > > > > > *De :* moose-dev-bounces(a)iam.unibe.ch [mailto: > moose-dev-bounces(a)iam.unibe.ch] *De la part de* Alexandre Bergel > *EnvoyÃ© :* lundi 17 aoÃ»t 2015 13:26 > *Ã :* Moose-related development > *Objet :* [Moose-dev] Re: Object new foo > > > > This is weird that such bug can be introduced and no alarm is raised > > > > Alexandre > > > Le 17 aoÃ»t 2015 Ã 08:03, Jan KurÅ¡ <kurs(a)iam.unibe.ch> a Ã©crit : > > Yep I had this problem (falled back to previous version), I suspected > debugger being the reason. > > Cheers Jan > > > > On Sun, 16 Aug 2015 03:05 Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > in Moose 6.0 simply freezes. > Anyone else sees this? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Aug. 25, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Guillermo Polito

Cool, tomorrow I'll sit next to you :). El mar., 25 de ago. de 2015 a la(s) 5:39 p. m., Thomas Heniart < heniart.thomas(a)gmail.com> escribiÃ³: > In Files-Tests 2 failures for me > BinaryFileStreamTest>>#testOpenFile > FileTest>>#testOpeningFileObjectCreatesFile > > Cheers, > Thomas > > 2015-08-25 17:30 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> 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

Re: [Pharo-dev] Strange Validation with issue 15820

by Thomas Heniart

In Files-Tests 2 failures for me BinaryFileStreamTest>>#testOpenFile FileTest>>#testOpeningFileObjectCreatesFile Cheers, Thomas 2015-08-25 17:30 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > 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

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