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

Re: [Pharo-project] Sticky morph after progress morph use

by Hilaire Fernandes

On 25/06/2012 13:30, StÃ©phane Ducasse wrote: > we do not know (at least I do not know what happened with the old progress bar). > Now in 2.0 it is fixed (yes I know that you need a 1.4 version). Great. DrGeo 12.07 will survive to it, later release will move to 2.0 anyway. Hilaire -- Dr. Geo -- http://www.drgeo.eu

June 27, 2012

Re: [Pharo-project] Zinc intermittently returning nil

by Sven Van Caekenberghe

Yes, that is *very* strange (latest 2.0, latest VM). Thanks a lot for reporting an intermittent bug, Sean ;-) On 27 Jun 2012, at 05:33, Sean P. DeNigris wrote: > The following all intermittently return nil. When I do the same thing in > Safari, I always seem to get the correct answer (plain text). > > (ZnEasy get: > 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') > contents. > > (ZnClient new get: > 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') > contents. > > (ZnUrl fromString: > 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') > retrieveContents. > > Even this returns nil intermittently (maybe less frequently, not sure): > client := ZnClient new. > client > systemPolicy; > url: > 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…'; > accept: ZnMimeType textPlain. > > client get contents. > > Sean > > -- > View this message in context: http://forum.world.st/Zinc-intermittently-returning-nil-tp4636820.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 27, 2012

Re: [Pharo-project] Zinc intermittently returning nil

by Schwab,Wilhelm K

I know *nothing* about Zinc, but my first thought is weak collections and how they are not thread safe (which they need to be) and are not self-repairing after finalization - they end up w/ retained nils. Dolphin blazed the correct trail on this in the mid to late 90s. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Tuesday, June 26, 2012 11:33 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Zinc intermittently returning nil The following all intermittently return nil. When I do the same thing in Safari, I always seem to get the correct answer (plain text). (ZnEasy get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') contents. (ZnClient new get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') contents. (ZnUrl fromString: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') retrieveContents. Even this returns nil intermittently (maybe less frequently, not sure): client := ZnClient new. client systemPolicy; url: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…'; accept: ZnMimeType textPlain. client get contents. Sean -- View this message in context: http://forum.world.st/Zinc-intermittently-returning-nil-tp4636820.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 27, 2012

[Pharo-project] Zinc intermittently returning nil

by Sean P. DeNigris

The following all intermittently return nil. When I do the same thing in Safari, I always seem to get the correct answer (plain text). (ZnEasy get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') contents. (ZnClient new get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') contents. (ZnUrl fromString: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') retrieveContents. Even this returns nil intermittently (maybe less frequently, not sure): client := ZnClient new. client systemPolicy; url: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…'; accept: ZnMimeType textPlain. client get contents. Sean -- View this message in context: http://forum.world.st/Zinc-intermittently-returning-nil-tp4636820.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by James Foster

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 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by Frank Shearar

On 26 June 2012 22:17, camille teruel <camille.teruel(a)gmail.com> wrote: > As far as I understand the video ofÂ GermÃ¡n's implementation, the import's > granularity is at the environment level, for both source-side and sink-side, > not at class level: he imports a whole environment into another. All the > class defined inside the source environment become accessible to the sink > environment without prefixing with the source environment name. > > IMO, the problems of importing a whole namespace into another are: > > you have to manage name clashes. > > Ex: you have a namespace A that imports namespaces B and C developped by > some other guys, then a guy add a class to B whose name is already used in C > for another class that A uses => A is now broken. > > you can't see how many dependencies a namespace has without doing some code > analysis. > > > However if you makes your imports class by class, you can see how many > dependency a namespace has and you are always sure that your code refers to > the classes you want. > >> 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: > > > You have to specify in which environment a class is at some point. If you > look at class builder, there is the super long method: > #name:inEnvironment:subclassOf:...... > For the moment, the environment is always the system dictionary. But if you > have several environements, you'll have to add the extra argument you don't > want when creating new classes. No: you store the current environment in a dynamic variable. ClassBuilder's convenience method checks the value of that variable, and you're done. If you look at the squeak-dev archives for today you'll see Colin Putney's Environment prototype which does exactly that. frank > BTW, do we want to have just namespace categories or a hierachical namespace > imbrication?

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by camille teruel

As far as I understand the video of GermÃ¡n's implementation, the import's granularity is at the environment level, for both source-side and sink-side, not at class level: he imports a whole environment into another. All the class defined inside the source environment become accessible to the sink environment without prefixing with the source environment name. IMO, the problems of importing a whole namespace into another are: - you have to manage name clashes. Ex: you have a namespace A that imports namespaces B and C developped by some other guys, then a guy add a class to B whose name is already used in C for another class that A uses => A is now broken. - you can't see how many dependencies a namespace has without doing some code analysis. However if you makes your imports class by class, you can see how many dependency a namespace has and you are always sure that your code refers to the classes you want. 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: You have to specify in which environment a class is at some point. If you look at class builder, there is the super long method: #name:*inEnvironment: *subclassOf:...... For the moment, the environment is always the system dictionary. But if you have several environements, you'll have to add the extra argument you don't want when creating new classes. BTW, do we want to have just namespace categories or a hierachical namespace imbrication?

June 26, 2012

Re: [Pharo-project] [update 2.0] #20162

by Sean P. DeNigris

Issue 6076: Pharo 2.0 Jenkins build trigger not working http://code.google.com/p/pharo/issues/detail?id=6076 I did a "Build now" to get to the latest update. From https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/urltriggerPo… : [URLTrigger] - Poll with a URL Inspecting Monitor a change of the content content for URL http://pharo.gforge.inria.fr/updates/pharo2.0/updates20.list Polling started on Jun 17, 2012 3:21:24 PM Polling for the job Pharo-2.0 Looking nodes where the poll can be run. Looking for a candidate node to run the poll. Looking for a polling node with the assigned project label pharo-build. Polling remotely on pharo-build Using Basic Authentication with the user 'bruni' [ERROR] - SEVERE - Polling error null -- View this message in context: http://forum.world.st/update-2-0-20162-tp4636765p4636789.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by StÃ©phane Ducasse

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 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: >> 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. > 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. > 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. > 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. If I want both, at the module import level I write Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint; > 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. > If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. > > James Foster > >

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by Schwab,Wilhelm K

+1 on not adding syntax. Never do to a language that which can be done with the language. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of James Foster [Smalltalk(a)JGFoster.net] Sent: Tuesday, June 26, 2012 3:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo and Namespaces 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. 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? > 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. 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. 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. In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) 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. If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. James Foster

June 26, 2012