- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Introducing Mars 0.1

by Damien Pollet

On Wed, Dec 24, 2008 at 19:43, Damien Pollet <damien.pollet(a)gmail.com> wrote: > PS. After re-reading Lukas's mails, Transcript and Workspace do work here too :) Actually, after implementing String class>>space, most windows worked ;) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 24, 2008

[Pharo-project] Issues 226 and 368

by HernÃ¡n Morales Durand

http://code.google.com/p/pharo/issues/detail?id=226 http://code.google.com/p/pharo/issues/detail?id=368 ( which lead to http://code.google.com/p/pharo/issues/detail?id=173 )

Dec. 24, 2008

Re: [Pharo-project] Introducing Mars 0.1

by Damien Pollet

On Sun, Dec 21, 2008 at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, I'm introducing Mars (just another world) Hi, tried it in Damien's dev image updated to pharo 10201, but it locks the image up :) When doing OBMarsWorld execute, the menu does change, but after that the image takes 100% cpu and will react to a couple interrupt keystrokes but that's it. I have to kill squeak. Maybe an incompatibility with another squeak plugin ? versions of OB ? PS. After re-reading Lukas's mails, Transcript and Workspace do work here too :) > Mars is a world for Squeak (and all it's forks) builded as an MVC on top of > Cocoa (OSX framework) and OmniBrowser. > For that reason, Mars just runs on OSX environments. > While this project has some similariries with SqueakGTK and wxSqueak, it has > big differences: > 1) Mars is not a port of Cocoa for squeak, is just an MVC implementation who > uses Cocoa. Why that "subtle" distinction? well, SqueakGTK is a full port of > GTK+ library and for that reason, a little big a and a little too complex. > I'm following simplicity as one of the project goals. > 2) Mars is a plugin, and will run in any fork of squeak, and OB-Mars (Mars > world) will run in any fork of squeak who can load OmniBrowser. This is a > big difference with wxSqueak, wich is a fork it self (and requires an > special VM) > And of course, while both efforts (SqueakGTK and wxWidgets) are cool, none > of them can be executed (and won't ever be) in small environments, like the > iphone, which is one of my main objectives (using John's new VM and Edgar's > work on minimal image building) > > Mars is MIT and can be downloaded following instructions from > here: http://www.smallworks.com.ar/productos/Mars/Download > For more details (history, blog, etc.), you can go > to: http://www.smallworks.com.ar/productos/Mars > DISCLAIMER: Right now, Mars is vere-very alpha stage (though it runs and can > be used) and I would love any contribution in the form of: bug reports > (there will be a lot now), feature requests, comments, and of course, code > :) > Cheers, > Esteban > -- > "Querer es suscitar las paradojas" > Camus. El mÃto de SÃsifo. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 24, 2008

[Pharo-project] Coverage of Collection test

by Alexandre Bergel

Hi, I was looking for an approximation of the coverage in the Collection tests. I wrote the following scripts. Maybe some of you have ideas to refine on how to refine it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-= | definedMethods testedMethods classCategory testCategory suffix classes untestedMethods testClasses | suffix := 'Abstract'. classCategory := 'Collections-', suffix. testCategory := 'CollectionsTests-', suffix. classes := Smalltalk allClasses select: [:cls | cls category = classCategory]. testClasses := Smalltalk allClasses select: [:cls | cls category = testCategory]. definedMethods := classes inject: Set new into: [:sum :cls | sum union: cls methodDictionary keys]. testedMethods := testClasses inject: Set new into: [:sum :cls | sum union: (cls methodDictionary values inject: Set new into: [:sums :cm | sums union: cm messages])]. "testedMethods contains all the methods send in test methods, which probably contains methods that have nothign to do with collection" testedMethods := testedMethods reject: [:sel | (definedMethods includes: sel) not]. untestedMethods := definedMethods select: [:selector | (testedMethods includes: selector) not]. { testedMethods . definedMethods . 'coverage =', (testedMethods size * 100 / definedMethods size) asFloat printString } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-= Here are the results so far CollectionsTests- Abstract = 7 % Arrayed = 15% Sequenceable = 54% SkipLists = 47% Stack = 61% Streams = 10% Support = 24% Text = 25% Unordered = 27% Weak = 11% I tried to make Christo run, but it seems that Reflectivity behaves strangely under Pharo. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Yes I contacted Janko if he can fix that On Dec 24, 2008, at 5:25 PM, Damien Pollet wrote: > On Wed, Dec 24, 2008 at 15:13, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: >> I do not think that a preference should relax some static language >> enforcements. > > Rule of thumb: if you just thought "maybe a preference would fix > thatâ¦" then you're avoiding the real problem :) > > I think the initial concern of Lukas is that it's a practical burden > to him if Pharo becomes too restrictive to load Seaside. So either > there is Swazoo and a couple other easy problems, and they should be > fixed quickly, or it's too much work to do the fixes and the compiler > should stay a bit permissive for the moment. Or Seaside doesn't work > on Pharo for some time. > > So I agree the conventions should be documented and breaking them > discouraged, but in practice it's probably more valuable to have > Seaside loading nicely than to have nice code NOW, and handle the > problem with a transition period like with deprecated methods. > >> I agree with Stephane, having a name that begins with a capitalized >> letter has a strong connotation of global visibility. And, on the >> contrary, an identifier beginning with a small letter has a >> restricted >> scope. > > Also in Ruby: $global @instVar @@classInstVar > â¦and in Java: int anInteger; > > Yes, enforcing is like static typing, and Code Critics is like > pluggable type systems :) > >> Forbidding a new value to be assigned to a method variable is a >> simple >> increase the readability. > > Why ? they are defined once at the beginning of the method, just not > between the | |; I think of them as locals that just get initialized > to something else than nilâ¦ > Now maybe I don't see the problem because I'm not used to C so it > wouldn't even occur to me that assigning to parameters could have an > effect on the caller. > >> Even if closure were supported, we should >> not allow a single identifier to appear as argument in different >> blocks in the same method. This does not help readability. > > Huh, do you really want to use :each1 :each2 :each3 if you have three > loops in the method ? > >> As a follower to that line, something that would be great to have, is >> to forbid accesses to an undefined variable. > > What if you remove the variable definition from the class ? Do you > want the compiler to force you to remove all uses immediately ? I do not think so but what would be good is to be aware of shadowed or used and not there variables because when you integrate code like we did and mike too. Shadowing is a plague because you do not know the code this is not yours and silently the compiler compiles and you have broken code but you do not do it. Dynamically typed does not weak. > > >> I am aware that I am talking as someone who does not maintain cross- >> dialect applications, but we cannot trade readability for a local in >> time commodity. > > Sure, but we could try to make the transition easier (e.g., complain > to Janko for the moment and wait until Pharo stable to enforce > conventions) Yes I think that this is the way to go Something like deprecated.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Damien Pollet

On Wed, Dec 24, 2008 at 15:13, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I do not think that a preference should relax some static language > enforcements. Rule of thumb: if you just thought "maybe a preference would fix thatâ¦" then you're avoiding the real problem :) I think the initial concern of Lukas is that it's a practical burden to him if Pharo becomes too restrictive to load Seaside. So either there is Swazoo and a couple other easy problems, and they should be fixed quickly, or it's too much work to do the fixes and the compiler should stay a bit permissive for the moment. Or Seaside doesn't work on Pharo for some time. So I agree the conventions should be documented and breaking them discouraged, but in practice it's probably more valuable to have Seaside loading nicely than to have nice code NOW, and handle the problem with a transition period like with deprecated methods. > I agree with Stephane, having a name that begins with a capitalized > letter has a strong connotation of global visibility. And, on the > contrary, an identifier beginning with a small letter has a restricted > scope. Also in Ruby: $global @instVar @@classInstVar â¦and in Java: int anInteger; Yes, enforcing is like static typing, and Code Critics is like pluggable type systems :) > Forbidding a new value to be assigned to a method variable is a simple > increase the readability. Why ? they are defined once at the beginning of the method, just not between the | |; I think of them as locals that just get initialized to something else than nilâ¦ Now maybe I don't see the problem because I'm not used to C so it wouldn't even occur to me that assigning to parameters could have an effect on the caller. > Even if closure were supported, we should > not allow a single identifier to appear as argument in different > blocks in the same method. This does not help readability. Huh, do you really want to use :each1 :each2 :each3 if you have three loops in the method ? > As a follower to that line, something that would be great to have, is > to forbid accesses to an undefined variable. What if you remove the variable definition from the class ? Do you want the compiler to force you to remove all uses immediately ? > I am aware that I am talking as someone who does not maintain cross- > dialect applications, but we cannot trade readability for a local in > time commodity. Sure, but we could try to make the transition easier (e.g., complain to Janko for the moment and wait until Pharo stable to enforce conventions) > Alexandre > > > On 23 Dec 2008, at 18:02, StÃ©phane Ducasse wrote: > >> lukas >> >> would a preference help? >> >> Stef >> >> On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: >> >>> Seaside depends on external packages, that we don't have control >>> over. >>> >>> For example there the Swazoo package contains a class-instance >>> variable that is uppercase. Unfortunately Pharo throws a notification >>> (instance variables should begin with a lower case characters) when >>> loading that code. This is awkward, because it makes it impossible to >>> load code automatically and gives us additional work. >>> >>> In my opinion a programming language should be as open as possible, >>> and if possible not restrict the user in any way, even if this is >>> against best practices. Unfortunately many of those restrictions are >>> built into our language that wouldn't be necessary: >>> >>> - class names and class-variable names are enforced to be uppercase >>> - class instance-variable names are enforced to be lowercase >>> - it is not possible to assign a new value to a method argument >>> - variable names are enforced to be unique in all scopes >>> >>> In my opinion the language should be as open as possible. It is the >>> purpose of Code Critics to point out smells, not the task of the >>> compiler to reject code that doesn't follow best practices. >>> >>> I am slightly frustrated trying to work around these restrictions ... >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 24, 2008

Re: [Pharo-project] A design question

by StÃ©phane Ducasse

I think that this is the morph scheduler model that is wrong. but unfortunately I'm not good enough in concurrent programming to fix. I remember that once nathanael told me that it was bogus by construction and that he understood how to do a good one. Too bad google took him :) On Dec 24, 2008, at 4:19 PM, Damien Pollet wrote: > On Wed, Dec 24, 2008 at 14:27, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> yes but so far none of the moprh class specialised this method. > > it's not used => remove it > >> On Dec 24, 2008, at 2:00 PM, Alexandre Bergel wrote: >>> It depends whether it makes sense or not to have a different >>> threshold >>> for objects. > > I'm not convinced by that threshold thing. If you need to update > something, either you have realtime constraints, or you just want to > limit CPU usage, in which case it's the scheduler's responsibility to > respect whatever low priority you give to the update taskâ¦ no? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Lukas Renggli

> Same with shadowed variables, a truly horrible idea. I look at code > and see an inst var, but fail to notice it is also an argument or > method var and I'm off being confused about what the code does. I never heard of a JavaScript, Java, C, C++, Ruby, Python, or Scheme programmer complain about shadowed variables. It makes sense to refer to a variable closest in scope shadowing those with the same name farther away. > or we should have a tool that point us to the shadowing. :) Code Critics already does that today. > If you allow abuse of the language, people will do it. Of course. That's why we have thisContext, #perform:, #become:, #nextInstance, #isKindOf:, #instVarAt:, etc. That's why we have Code Critics that reminds people to be careful about these things. That's also the reason why there is Seaside. And that's why there is no Seaside for Java. >> Same for upper/lowercase conventions, let alone uppercase method >> names. >> >> Breaking the kind of conventions makes you think harder about what >> code does and that distracts you from what you really trying to do. Or >> should be doing ;-) I like the metaphor of global being uppercase and local being lowercase. I don't see a point enforcing that though: The meaning of global and local is rather arbitrary. In the context of the subclasses of a class all instance variables are global. In the context of a method the method arguments are global as well. There is a big difference between syntax and coding conventions: 1. Syntax: This is what the compiler can compile unambiguous. This is the syntax as found in the back of the Smalltalk-80 book. This is the grammar that deterministically decides if a program can be compiled or not. For portability it should follow the ANSI standard as close as possible. Note that the ANSI standard does not restrict names of globals, classes, inst-vars, class inst-vars, class-vars, pools, methods, temps, ... in any way: they are all identifiers, starting with an upper or lowercase letter, followed by zero or more letters or digits. If it is decided to restrict these names, Pharo won't be ANSI compatible anymore. 2. Coding Conventions: This is what the community decides to follow and what every serious open source project should publish somewhere on the web. This includes rules like "temps and instance variables are lowercase" or "code is formatted with tabs and there are no empty lines". For Seaside we have such rules and we rigorously reject/rewrite code that does not follow these guidelines, see <http://www.seaside.st/community/conventions>. We use Code Critics to detect violations against these rules or to automatically fix poroblems. This ensures a high quality of the core code, but still enables other parties to write and use code that does not follow these conventions. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 24, 2008

Re: [Pharo-project] A design question

by Damien Pollet

On Wed, Dec 24, 2008 at 14:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > yes but so far none of the moprh class specialised this method. it's not used => remove it > On Dec 24, 2008, at 2:00 PM, Alexandre Bergel wrote: >> It depends whether it makes sense or not to have a different threshold >> for objects. I'm not convinced by that threshold thing. If you need to update something, either you have realtime constraints, or you just want to limit CPU usage, in which case it's the scheduler's responsibility to respect whatever low priority you give to the update taskâ¦ no? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

On Dec 24, 2008, at 3:13 PM, Alexandre Bergel wrote: > I do not think that a preference should relax some static language > enforcements. > Contrary to Java, the Smalltalk community does not appear to be big > enough to have these problem unsolvable. > > I agree with Stephane, having a name that begins with a capitalized > letter has a strong connotation of global visibility. And, on the > contrary, an identifier beginning with a small letter has a restricted > scope. > > Forbidding a new value to be assigned to a method variable is a simple > increase the readability. Even if closure were supported, we should > not allow a single identifier to appear as argument in different > blocks in the same method. This does not help readability. > > As a follower to that line, something that would be great to have, is > to forbid accesses to an undefined variable. or we should have a tool that point us to the shadowing. :) > > > I am aware that I am talking as someone who does not maintain cross- > dialect applications, but we cannot trade readability for a local in > time commodity. > > Alexandre > > > On 23 Dec 2008, at 18:02, StÃ©phane Ducasse wrote: > >> lukas >> >> would a preference help? >> >> Stef >> >> On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: >> >>> Seaside depends on external packages, that we don't have control >>> over. >>> >>> For example there the Swazoo package contains a class-instance >>> variable that is uppercase. Unfortunately Pharo throws a >>> notification >>> (instance variables should begin with a lower case characters) when >>> loading that code. This is awkward, because it makes it impossible >>> to >>> load code automatically and gives us additional work. >>> >>> In my opinion a programming language should be as open as possible, >>> and if possible not restrict the user in any way, even if this is >>> against best practices. Unfortunately many of those restrictions are >>> built into our language that wouldn't be necessary: >>> >>> - class names and class-variable names are enforced to be uppercase >>> - class instance-variable names are enforced to be lowercase >>> - it is not possible to assign a new value to a method argument >>> - variable names are enforced to be unique in all scopes >>> >>> In my opinion the language should be as open as possible. It is the >>> purpose of Code Critics to point out smells, not the task of the >>> compiler to reject code that doesn't follow best practices. >>> >>> I am slightly frustrated trying to work around these >>> restrictions ... >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008