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

Re: [Pharo-project] Pharo and Namespaces

by Sean P. DeNigris

GermÃ¡n Leiva wrote > > OT: Late binding rocks! > Yes, and the latest binding would be to lookup at runtime. I have no idea what the performance hit would be, or if we would use all that power, but the idea is exciting :) -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 27, 2012

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Sean P. DeNigris

Dario Trussardi wrote > > OK, but how i can integrate the new VM with my hold image ? > ... > For now i copy the: > > PharoV10.sources > *.image > *.change > > into the new CogVM / Contents / Resources > You got it! You actually just need the image and changes files. If you had used the standalone VM that Sven linked to, you'd hook it up with your image in the standard Mac app ways, e.g.: * double click on the VM... a window will pop up to select an image * from the command line - /path/to/CogVm (inside the .app) my_image.image - open CogWhatever.app ... -- View this message in context: http://forum.world.st/Pharo-1-4-and-Zodiac-tp4636907p4636977.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 27, 2012

[Pharo-project] [update 2.0] #20167

by Marcus Denker

20167 ----- Issue 6176: Add Zodiac https support (add Zinc-Zodiac) http://code.google.com/p/pharo/issues/detail?id=6176 Issue 6181: put order on SUnit-Core-Utilities http://code.google.com/p/pharo/issues/detail?id=6181 -- Marcus Denker -- http://marcusdenker.de

June 27, 2012

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by Guillermo Polito

I've spent 3 hours on trying to understand deeply the Multilingual mess, but I'm dying in the process... It mixes environments with charsets... Some charsets and converters are for really old OS versions... Sometimes it uses unicode, some times not... argggdsdsa On Wed, Jun 27, 2012 at 5:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > ok but how can we build a concrete roadmap. > What are the steps that we can take and perform one by one. > > Stef > > On Jun 27, 2012, at 3:11 PM, Henrik Sperre Johansen wrote: > > > On 25.06.2012 18:06, Denis Kudriashov wrote: > >> Hello. > >> > >> What is responsibility of environments (russian, japanese) classes. > >> Why its needed? Why converter classes not enough? > >> > >> For example, I can write russian text at workspace without setting any > specific russian environment. I only need specific fonts for this. > >> > > Novadays, they can be used to read number/date printing policies, decide > which translation package to use, etc. Basically what you'd expect from an > OS locale, but more limited in capabilities. > > > > The part linked to charsets and encodings seem to me an anachronism from > when the OS's used different encodings based on the selected environment > though. (so files would be read and written automatically with the correct > (non-unicode) encoding, and potentially displayed using a different bitmap > font through selection using leadingChar) > > > >> 2012/6/25 Guillermo Polito <guillermopolito(a)gmail.com> > >> Hi guys, > >> > >> I'm trying to understand the Multilingual packages to get things a bit > more reorganized. This way we can start to have a simpler and > understandable kernel. So, > >> > >> - We have all environments(greek, chinese, japanese, korean, > russian...) in the same package. Each environment has it's associated > charset, and text converter, which are in different packages. Also, each > text converter has a table of conversions between unicode and the encoding. > But all converters are together, and all charsets are together. > >> > >> What about putting related things together? I mean, japanese converter > with japanese environment with japanese charset in one package. Same with > russian, korean, chinese... Does it make sense? This way we should be > able to unload one of them if we do not really need it. > >> > > > >> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside > Multilingual-TextConversion? Even, they do the same on top of a file or a > memory stream of bytes (or they say so in the comment :^D )... > >> > >> What about merging them? using a decorator? They have a lot in > common... :/ Put them in a different package? > > They are not neatly composed. > > Trying to merge them so the methods work with a file and > bytearray/string backend equivalently would probably only make things even > worse. > > Using a decorator would be hard, since the MultiByteFileStream method > implementations use alot of its inherited behaviour. > > > > As for putting them in a different package, sure you can peddle crap > around all you want, but that doesn't make it stink any less. > >> > >> - Just curious. ImmPlugin is working or shipped with vms? Not for > macos, because there is no macos implementation. Then, the class comment > says: > >> > >> "On Windows, the plugin is not provided in the shipped VM's, and its > current whereabouts are uncertain. > >> > >> On Unix, the only implemented behaviour is setting the position when > over-the-spot precomposition of characters is the current mode. > >> > >> In the VM, the mode is chosen to the first available valid mode > returned by the X Server, so whether this is actually relevant at all > depends on the X Server." > >> > >> So, does someone use it and see value on keeping it? > > > > Sure, there is value in neatly integrating OS input methods for composed > characters. > > > > Whether that belongs in a plugin of it's own, and whether what the > plugin currently offers justifies its existence, is a different question, > which I guess the removal was the answer to. :) > > > > To find any potential actual users, I guess you'd have to find a pharo > app localized to the eastern hemisphere and have it ask their linux users > if they appreciate it/if it works. > > That, or a developer from the same area who codes in his native language > (which will be hard I think, given arbitrary tool constraints wrt message > names etc.) > > > > Cheers, > > Henry > > >

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by StÃ©phane Ducasse

On Jun 27, 2012, at 4:44 PM, James Foster wrote: > Stef, > > I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist. yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have. Stef > > Best wishes, > > James > > On Jun 27, 2012, at 12:08 AM, StÃ©phane Ducasse wrote: > >> James >> >> sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). >> We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock >> if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. >> And yes I read the implementation two years ago. >> Finally did you see the list of topics that I mention? >> - do you want to help in any of them to make pharo better? >> because we have to get them first and I need all my energy for them. >> >> Stef >> >> >> On Jun 27, 2012, at 12:25 AM, James Foster wrote: >> >>> On Jun 26, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: >>> >>>> On Jun 26, 2012, at 9:30 PM, James Foster wrote: >>>> >>>>> On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: >>>>> >>>>>>>>> What happened to the project from GermÃ¡n Leiva >>>>>>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>>>>>>> >>>>>>>> we do not want class level namespace because this is the mess >>>>>>> >>>>>>> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. >>>>>> >>>>>> We do not want to have class name resolution at the granularity of a class. >>>>> >>>>> And are you saying this because you think GermÃ¡n's implementation does this? >>>>> >>>>>> Why because it means that in the same package reading the code containing a class Foo could be a different one. >>>> >>>>>> Why because it means that in the same package, reading the code containing a class Foo could be a different one. >>>> ^^^^^ >>>> >>>> Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace. >>> >>> I still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods. >>> >>> Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"? >>> >>>>> I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? >>>> >>>> No >>>> I just say that changing binding of variables at the class level is not a good granularity. I do not want to have >>>> >>>> Object subclass: #NameOfSubclass >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'Bob' >>>>>>> environment: >>> >>> Is it your impression that GermÃ¡n's implementation requires this? If so, on what do you base that understanding? Have you looked at the code? >>> >>>>>> I'm saying that since years. >>>>> >>>>> I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. >>>> >>>> because this is a class level import. >>> >>> I still don't know what you mean by "class level import" or why you think GermÃ¡n's implementation fits your definition. >>> >>>>> Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. >>>> >>>> Usually this is the class of the method. >>> >>> By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime? >>> >>>>> This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. >>>> >>>> no this is a question of language design. >>> >>> Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug. >>> >>>>> In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) >>>> >>>> No we do not want to have that. >>>> We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. >>> >>> By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened? >>> >>>> If I want both, at the module import level I write >>>> >>>> Import: Point from: core as: CorePoint; >>>> import: Point from: dev as: DevPoint; >>> >>> What object implements #'import:from:as:'? >>> >>>>> or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. >>>> >>>> I dislike them both. >>>> A module should provide a certain level of encapsulation, else naming convention is good enough. >>>> Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use. >>> >>> You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean. >>> >>> I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required. >>> >>> If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)? >>> >>> What I understand from your statements so far is that GermÃ¡n's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it? >>> >>> Thanks for engaging in the discussion. >>> >>> James Foster >>> >>> >> >> >> > >

June 27, 2012

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by StÃ©phane Ducasse

ok but how can we build a concrete roadmap. What are the steps that we can take and perform one by one. Stef On Jun 27, 2012, at 3:11 PM, Henrik Sperre Johansen wrote: > On 25.06.2012 18:06, Denis Kudriashov wrote: >> Hello. >> >> What is responsibility of environments (russian, japanese) classes. >> Why its needed? Why converter classes not enough? >> >> For example, I can write russian text at workspace without setting any specific russian environment. I only need specific fonts for this. >> > Novadays, they can be used to read number/date printing policies, decide which translation package to use, etc. Basically what you'd expect from an OS locale, but more limited in capabilities. > > The part linked to charsets and encodings seem to me an anachronism from when the OS's used different encodings based on the selected environment though. (so files would be read and written automatically with the correct (non-unicode) encoding, and potentially displayed using a different bitmap font through selection using leadingChar) > >> 2012/6/25 Guillermo Polito <guillermopolito(a)gmail.com> >> Hi guys, >> >> I'm trying to understand the Multilingual packages to get things a bit more reorganized. This way we can start to have a simpler and understandable kernel. So, >> >> - We have all environments(greek, chinese, japanese, korean, russian...) in the same package. Each environment has it's associated charset, and text converter, which are in different packages. Also, each text converter has a table of conversions between unicode and the encoding. But all converters are together, and all charsets are together. >> >> What about putting related things together? I mean, japanese converter with japanese environment with japanese charset in one package. Same with russian, korean, chinese... Does it make sense? This way we should be able to unload one of them if we do not really need it. >> > >> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside Multilingual-TextConversion? Even, they do the same on top of a file or a memory stream of bytes (or they say so in the comment :^D )... >> >> What about merging them? using a decorator? They have a lot in common... :/ Put them in a different package? > They are not neatly composed. > Trying to merge them so the methods work with a file and bytearray/string backend equivalently would probably only make things even worse. > Using a decorator would be hard, since the MultiByteFileStream method implementations use alot of its inherited behaviour. > > As for putting them in a different package, sure you can peddle crap around all you want, but that doesn't make it stink any less. >> >> - Just curious. ImmPlugin is working or shipped with vms? Not for macos, because there is no macos implementation. Then, the class comment says: >> >> "On Windows, the plugin is not provided in the shipped VM's, and its current whereabouts are uncertain. >> >> On Unix, the only implemented behaviour is setting the position when over-the-spot precomposition of characters is the current mode. >> >> In the VM, the mode is chosen to the first available valid mode returned by the X Server, so whether this is actually relevant at all depends on the X Server." >> >> So, does someone use it and see value on keeping it? > > Sure, there is value in neatly integrating OS input methods for composed characters. > > Whether that belongs in a plugin of it's own, and whether what the plugin currently offers justifies its existence, is a different question, which I guess the removal was the answer to. :) > > To find any potential actual users, I guess you'd have to find a pharo app localized to the eastern hemisphere and have it ask their linux users if they appreciate it/if it works. > That, or a developer from the same area who codes in his native language (which will be hard I think, given arbitrary tool constraints wrt message names etc.) > > Cheers, > Henry

June 27, 2012

[Pharo-project] [update 2.0] #20166

by Marcus Denker

20166 ----- Issue 6185: Number>>#@ should not be part of Graphics http://code.google.com/p/pharo/issues/detail?id=6185 Issue 6143: MIME decoding and Unicode not working http://code.google.com/p/pharo/issues/detail?id=6143 -- Marcus Denker -- http://marcusdenker.de

June 27, 2012

[Pharo-project] [update 2.0] #20165

by Marcus Denker

20165 ----- Issue 6184: Clean LanguageEnvironment initialization and startup http://code.google.com/p/pharo/issues/detail?id=6184 Issue 6177: Refactor in ClassSearch http://code.google.com/p/pharo/issues/detail?id=6177 Issue 6179: InMidstOfFileinNotification is used everywhere - recategorize it http://code.google.com/p/pharo/issues/detail?id=6179 Issue 6182: ClassTestCase depends on Text http://code.google.com/p/pharo/issues/detail?id=6182 -- Marcus Denker -- http://marcusdenker.de

June 27, 2012

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Dario Trussardi

Ciao > > Dario Trussardi wrote >> >> Ok, i download it for MAC and paste it into Pharo-1.4-one-click content. >> > > If you want to use the one-click (which contains the VMs for > Windows/Mac/Linux and the image), just download the pre-made one for Pharo > 1.4 at > https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… > > I just confirmed that it works on Mac Lion - i.e. all the Zodiac tests pass > after loading as Sven indicated above. > > In the future, for more flexibility, you can download a vm as Sven suggested > and use it with your image. You can kind of think of the vm as the > application and the image as the document, or if you're familiar with a > language like ruby, the vm is something like the ruby interpreter. OK, but how i can integrate the new VM with my hold image ? How i can do it? What file i need to copy in the new VM? For now i copy the: PharoV10.sources *.image *.change into the new CogVM / Contents / Resources It's complete or i need to copy more things ? After i do the command for load gofer relative to Zinc and Zodiac and now all work fine. Thanks, Dario > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Pharo-1-4-and-Zodiac-tp4636907p4636931.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by James Foster

Stef, I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist. Best wishes, James On Jun 27, 2012, at 12:08 AM, StÃ©phane Ducasse wrote: > James > > sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). > We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock > if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. > And yes I read the implementation two years ago. > Finally did you see the list of topics that I mention? > - do you want to help in any of them to make pharo better? > because we have to get them first and I need all my energy for them. > > Stef > > > On Jun 27, 2012, at 12:25 AM, James Foster wrote: > >> On Jun 26, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: >> >>> On Jun 26, 2012, at 9:30 PM, James Foster wrote: >>> >>>> On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: >>>> >>>>>>>> What happened to the project from GermÃ¡n Leiva >>>>>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>>>>>> >>>>>>> we do not want class level namespace because this is the mess >>>>>> >>>>>> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. >>>>> >>>>> We do not want to have class name resolution at the granularity of a class. >>>> >>>> And are you saying this because you think GermÃ¡n's implementation does this? >>>> >>>>> Why because it means that in the same package reading the code containing a class Foo could be a different one. >>> >>>>> Why because it means that in the same package, reading the code containing a class Foo could be a different one. >>> ^^^^^ >>> >>> Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace. >> >> I still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods. >> >> Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"? >> >>>> I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? >>> >>> No >>> I just say that changing binding of variables at the class level is not a good granularity. I do not want to have >>> >>> Object subclass: #NameOfSubclass >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Bob' >>>>>> environment: >> >> Is it your impression that GermÃ¡n's implementation requires this? If so, on what do you base that understanding? Have you looked at the code? >> >>>>> I'm saying that since years. >>>> >>>> I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. >>> >>> because this is a class level import. >> >> I still don't know what you mean by "class level import" or why you think GermÃ¡n's implementation fits your definition. >> >>>> Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. >>> >>> Usually this is the class of the method. >> >> By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime? >> >>>> This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. >>> >>> no this is a question of language design. >> >> Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug. >> >>>> In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) >>> >>> No we do not want to have that. >>> We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. >> >> By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened? >> >>> If I want both, at the module import level I write >>> >>> Import: Point from: core as: CorePoint; >>> import: Point from: dev as: DevPoint; >> >> What object implements #'import:from:as:'? >> >>>> or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. >>> >>> I dislike them both. >>> A module should provide a certain level of encapsulation, else naming convention is good enough. >>> Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use. >> >> You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean. >> >> I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required. >> >> If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)? >> >> What I understand from your statements so far is that GermÃ¡n's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it? >> >> Thanks for engaging in the discussion. >> >> James Foster >> >> > > >

June 27, 2012