November 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] SimpleTraits - How can we have Traits/Mixins quickly?

by Peter van Rooijen

On Mon, 22 Nov 2010 10:45:30 +0100, Marcus Denker <marcus.denker(a)inria.fr> wrote: 1) Those that block any change because Smalltalk is not supposed to be changed by mortals. 2) Those that want to go "beyond Smalltalk". But it has to be perfect! So better do nothing. (Aka: The Squeak Desease). This is the far greater problem. <old man story snipped> Marcus, you are so right! We should not wait to *share* until what we have made is perfect (or fully functional, or polished or some other excuse for not sharing). Let me tell you a story of my own. I was at a Smalltalk meeting in Cologne a little while ago and it was my first time there and I did not know the people there. I thought: let me, as a newcomer, try to contribute in return for their organizing effort and hospitality. So I said I would be happy to show some code (a class) that I had written and that I used a lot and found very useful. They said please show us, so I browsed the class and its tests and a few examples and showed most of the code and answered a few questions and we had a little discusion. During the break a few guys said to me we should have more of these presentations, where someone shows code. I said: so why don't you do that more? And you know what the core answer was? Everyone is more or less ashamed to show their code because they think it is not very good. Will you believe that I was very surprised to hear that THAT was the problem? My own code, which I showed, was ugly, incomplete, unfinished, inconsistent in places. But I knew that it had value, because it implemented ONE valuable IDEA effectively. I had been using it for several years and always just implemented what I needed the code to do. I didn't care that other people saw my unpolished code, in fact I was happy and hoped they would give me some inspiration to maybe improve it, or more motivation to share it more widely than I had done. So I agree, imperfect solutions have value and please do not feel afraid to share what is not "perfect"! BABBAGE But the Babbage in the story had a point too. Continuing on something that you know you can't finish seems irrational and the fact that his replacement projects were also unattainable does not mean that he should have continued with the old stuff. If you work only for yourself, you can of course do what you want. TRAITS/MIXINS But what about these traits? I don't understand what all the fuss is about. Wasn't the point of Traits that it is *sooo* frustrating to have to duplicate all kinds of code in various classes, which wouldn't be necessary in a multiple inheritance language? And *sooo* frustrating that we would love to refactor Collections and stuff but we can't because of we only have subclass inheritance? But full-fledged multiple inheritance is too much work, too big a step, or we could never agree on the semantics/details... And isn't there a problem in that the browsers expect classes and not traits and that it is too much work to change the tools, expecially as they are moving targets? If these are really the problems, then why can't we simply allow a class to mix in another class? Could that be a 70% (imperfect) solution, for 10% of the effort? Class1 mixIn: Class2 CONFLICTS CANNOT EXIST Class2 must be suitable to be mixed in with Class1 or the operation fails. If it succeeds, the definition of the second class is merged into that of the first. If we change either class, these changes are acceptable only if the two classes remain compatible for mixing and the compiler must take into account the dependencies so that when a mixed in class is changed, the compatibility is verified and the receiving class is recompiled as required ANY class can be mixed in to another as long as they are compatible for mixing. No tools need be updated. The class definition source will not change. There WILL have to be a class method something like mixInClasses ^ {Class2 . Class3} Of course some smart person will teach the browsers about this method but there is no requirement for this. At first all that is needed is that the compiler knows to use this method to make sure that Class1 is compiled as if the mixed in classes were part of its definition. There will be NO RENAMING of anything to resolve conflicts. Conflicts simply cannot exist. All the variable names (instance, class, class instance, pool) in the definitions of both classes will remain the same when mixing is done. instance, class instance, and pool variables with the same name in both classes can, by nature, never "clash". Class variables will refer to the same variable in both classes if both mixed classes inherit the class variable from the same superclass, or to a different one in each class otherwise. If a method with the same name exists in a class AND its mixin (as will happen when you mix a class with at least one method in to another), they must have the same definition. Programmers defining classes for the purpose of mixing them in will simply have to take these limitations into account. This is nothing new or special; with subclass inheritance there are also things you can and things you cannot do, and the compiler already takes al the relevant rules into account and enforces compliance. HOW TO USE When you have this mixin scheme in your image, you can start with an empty Class2 or with Class2 being a copy of the Class1 and mix Class2 into Class1. The effect on Class1 is the same since conflicts cannot exist. You can then proceed to remove methods from either class, add methods (if added to the trait, they will also be added to the base), remove methods (removing only from the base will have no effect), change methods (synchronized). In short, you can gradually and incrementally reorganize the code in your image, without changing any functionality. All the existing tools for code management keep on working Later on people will figure out to improve the browsers, and to remove duplication in the compiled structures. But for a start we can remove a whole class of source duplication and this seems a worthy goal. HOW MUCH WORK SimpleTraits should not be more than a few days work for someone reasonable familiar with the compiler infrastructure. (Of course I have no idea but I can conjecture). Does anyone think they would want to use it if it existed? Who will build this and give a nice Christmas present to the community? I hereby donate the design inasfar as it contributes anything original, and provided it is implemented and integrated in Pharo within 6 months :-). Cheers, Peter P.S. Traits/MixIns? For SimpleTraits, I would propose to keep both names. We say we mix in (the compiler mixes in) a class using Class1 mixIn: Class2. The compiler finds the mixInClasses from the methods with the same name. When we talk about Class1 and Class2 in relation to each other we call Class1 the base, and Class2 the trait (of course both classes can conceivably play the other role as well, in other mixin relationships, but we need not concern ourselves with this at first and simply not implement multi-stage mixin relationships although this may become desired at some later point in time). P.P.S. StÃ©phane, let me know if this SimpleTraits design addresses what you require from a Traits system. I had dreamed up this design some time ago but thought Traits were already "there". Now it seems that Traits have somehow not "made it" into Pharo and I believe with you that it is a shame not to have it. P.P.P.S. Inherited elements (vars, methods) of a trait class are (of course) part of what is synchronized and shared with its bases so be mindful of what you inherit!

Nov. 29, 2010

Re: [Pharo-project] Issue 3356 in pharo: AllocationTest>>#isSafeVM

by pharo＠googlecode.com

Comment #2 on issue 3356 by Benjamin.VanRyseghem.Pharo: AllocationTest>>#isSafeVM http://code.google.com/p/pharo/issues/detail?id=3356 probably ^^ but I do not know how to do that :)

Nov. 29, 2010

Re: [Pharo-project] Issue 3356 in pharo: AllocationTest>>#isSafeVM

by pharo＠googlecode.com

Comment #1 on issue 3356 by siguctua: AllocationTest>>#isSafeVM http://code.google.com/p/pharo/issues/detail?id=3356 i'm sorry, but isn't it would be more correct to check VM version by querying VM itself, rather than trying to determine its version based on file/directory names?

Nov. 29, 2010

[Pharo-project] TextConverter handling of binary streams

by Sven Van Caekenberghe

Hi, TextConverter and its subclasses seem to break the contract of #nextFromStream: and #nextPut:toStream: when the stream #isBinary. Consider the following two examples: ByteArray streamContents: [ :stream | | encoder | encoder := UTF8TextConverter new. 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]. #[233 108 232 118 101 32 101 110 32 102 114 97 110 231 97 105 115] (String streamContents: [ :stream | | encoder | encoder := UTF8TextConverter new. 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]) asByteArray. #[195 169 108 195 168 118 101 32 101 110 32 102 114 97 110 195 167 97 105 115] The first answer is incorrect, the second is correct (as far as I understand it). This is apparently on purpose, from the implementation of, for example, UTF8TextConverter>>#nextPut:toStream: nextPut: aCharacter toStream: aStream | leadingChar nBytes mask shift ucs2code | aStream isBinary ifTrue: [^aCharacter storeBinaryOn: aStream]. leadingChar := aCharacter leadingChar. (leadingChar = 0 and: [aCharacter asciiValue < 128]) ifTrue: [ aStream basicNextPut: aCharacter. ^ aStream. ]. "leadingChar > 3 ifTrue: [^ aStream]." ucs2code := aCharacter asUnicode. ucs2code ifNil: [^ aStream]. nBytes := ucs2code highBit + 3 // 5. mask := #(128 192 224 240 248 252 254 255) at: nBytes. shift := nBytes - 1 * -6. aStream basicNextPut: (Character value: (ucs2code bitShift: shift) + mask). 2 to: nBytes do: [:i | shift := shift + 6. aStream basicNextPut: (Character value: ((ucs2code bitShift: shift) bitAnd: 63) + 128). ]. ^ aStream. I would say that the contract of #nextPut:toStream: is to take a Character object and write a binary representation using a specific encoding to a stream. However, when given a #isBinary stream, it does no longer do any encoding at all ! The same is true for the other converters as well as for #nextFromStream:. Does anyone know why that is the case ? And if it is by design, how should one do UTF8 encoding on a binary stream ?? Thx, Sven PS: If others also think this is strange, I could make an issue, I am just not sure this is a bug.

Nov. 29, 2010

Re: [Pharo-project] <script language="smalltalk">

by Igor Stasenko

On 29 November 2010 13:24, <csrabak(a)bol.com.br> wrote: > Em 28/11/2010 18:17, Igor Stasenko < siguctua(a)gmail.com > escreveu: > >> On 28 November 2010 19:41, wrote: >> > Em Â 26/11/2010 Â 16:25, Janko Â MivÅ¡ek Â < janko.mivsek(a)eranova.si Â > >> >escreveu: >> >> On 26. 11. 2010 Â 18:20, csrabak(a)bol.com.br wrote: > Em 24/11/2010 >> >> 11:50, Jan van de Sandt < jvdsandt(a)gmail.com > escreveu: >> >> >> >> >> A Smalltalk variant would use Smalltalk as the source language >> >> >> instead of Java, the other parts of GWT can be reused. Â GWT is >> >> >> open source (Apache 2.0 license). >> >> >> >> > I think we Â have first to evaluate to Â what audience/market are >> >> > thinking of targeting this effort, then estimate the effort, in >> >> > order to see if its worth it. >> >> Â Specially we the Â web guys are very interested Â of such a beast, >> >> because we need to develop more in more on the client side and in >> >> JavaScript, which is a bit hard, because of our Smalltalk habits, >> >> you know :) >> > I Â _do_. Â However, Â it Â is Â also Â a major Â trend Â "in Â this Â vital >> > industry"Â¹ the increase in restrictions on the client side leading >> > a Â lot Â of Â developers Â to Â switch from Â Javascript Â (client Â side >> > computing) to Â PHP (server Â side computing), for Â an example Â of a >> > popular site which ostensibly writes it in its home page, look at: >> > http://www.quantitativeskills.com/sisa/Â² >> > same problem Â again: why doing things twice Â (write same things in >> javascript on Â client side, Â and then rewrite Â same thing in Â PHP on >> server side). Why, Â i am asking, why server and Â client side have to >> use Â different Â languages? Â Why Â industry Â created Â such Â ridiculous >> standards, which Â forcing us to use multiple Â languages depending on >> environment? Â A CouchDB, for example, by default supports javascript >> as Â a scripting Â language for Â views Â on server. Â This means, Â that >> people to build Â their site & persistency, have Â to know only single >> language Â - javascript. No Â PHP, no Â SQL and Â other rusty Â pieces of >> technology. :) > > Perhaps my example has been misunderstood because I've put it in the > fly without more explanation: the developers at SISA will _replace_ > client side code with server side code and opted for PHP for whichever > reason they felt to do so. > yeah.. good luck then :) > Attempting to answer your question about "why server and Â client side > have to use Â different Â languages?" is a subject for another thread, > but in nutshell it can be explained by the "one size does not fit all" > moto. > that was a rhetoric question. I don't think that it is necessary to port code for calculating statistical data, if you using same language. Because its just a numerical processing, and should be no different no matter where you running it. What may need changing is I/O interfaces, when you moving from client to server side. This means a lot less work comparing to porting everything into another language. > What's "rusty" or "classic" or "proven" technology is in the > beholder's eyes.... for a lot of 'gurus' Smalltalk is 'rusty' or > 'antique' and belongs to museum. > It is my personal view, of course. Rusty because, every time i need to fix something in PHP or Javascript, often i have no other ways, but just put ' echo $foo ' in PHP, and alarm(foo) in javascript to see what wrong with data, instead of simply seeing same variable (and a lot of other related vars) directly in debugger. This is what makes me angry every time , because i used to have debugger & browser in smalltalk, constantly available at any moment under my fingertips. The problem with these languages, i think, that they were evolved from very simple and very limited initial requirements, which later grew to more and more powerful & flexible features, once users started demanding more. In contrast to smalltalk, where its structure & design (including environment) were took multiple iterations before final one , which then made public. Ruby and Perl, i think, having same ill fundament. They were created with no strategy in mind: its just a toys which later became professional instruments, because of gaining popularity. Both lacking systematic approach in design. And the reason why they all fail will be same: no strategy & systematic design from very starting. You can't build a plane without planning stages and knowing exactly what materials you will need for every detail. It will never fly. > About "Why Â industry Â created..." the answer comes from marketting > forces and attempts to 'lead' or 'gain market share'. > >> >> > "Security" reasons plus less Â acquaintance with a newer technology >> > would Â make Â this Â entry Â in Â the Â market Â very Â hard Â in Â today's >> > environments. >> > Perhaps what's _really_ needed is a good Javascript debugger? >> > perhaps. And Self-like object's inspectors and explorers :) >> > [snipped] > >> > So, Â rephrasing my Â point above: Â except if Â we can Â produce those >> > artifacts as a simple Â consequences of subclassing some objects in >> > our Â environments and Â having a Â robust enough Â usable Â system, we >> > rather consider Â carefully the use Â of our efforts in Â other areas >> > where the fruits are hanging lower. >> > Yes, i agree. Such plugin would require a big efforts to complete. >> And while from Â tech side, we can foresee Â the benefits, from market >> side, Â this is Â not obvious. Â Because Â niche is Â already filled Â by >> javascript, which Â is also dynamic Â language and very Â powerful one. >> What lacking, is a development environment for javascript, which can >> be Â used Â to Â develop Â things Â as Â same pace Â as Â in Â smalltalk Â dev >> environment. >> > > Yes, like Eclipse ends up 'borrowing' a lot of features from Smalltalk > environments and seems to those new wave of developers as genuine > 'new' ideas, I think Smalltalk can at most be like a reference model > for this. > > Regards, > > -- > Cesar Rabak > > -- Best regards, Igor Stasenko AKA sig.

Nov. 29, 2010

[Pharo-project] Issue 3356 in pharo: AllocationTest>>#isSafeVM

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3356 by Benjamin.VanRyseghem.Pharo: AllocationTest>>#isSafeVM http://code.google.com/p/pharo/issues/detail?id=3356 This code isSafeVM "False if the VM is a Unix VM that has not been updated to version 4. Earlier versions may be subject to a bug that can crash the VM when running AllocationTest." self flag: #toRemove. "April 2010 dtl - remove this about one year from now" ^ Smalltalk isUnix not or: [((Smalltalk vmFullPath findTokens: FileDirectory slash) select: [:e | e beginsWith: '4.']) isEmpty not] Should be changed by : isSafeVM "False if the VM is a Unix VM that has not been updated to version 4. Earlier versions may be subject to a bug that can crash the VM when running AllocationTest." self flag: #toRemove. "April 2010 dtl - remove this about one year from now" ^ Smalltalk isUnix not or: [((Smalltalk vmFullPath findTokens: FileDirectory slash) anySatisfy: [:e | e beginsWith: '4.'])]

Nov. 29, 2010

[Pharo-project] Issue 3354 in pharo: Clean of RecentMessageList

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3354 by Benjamin.VanRyseghem.Pharo: Clean of RecentMessageList http://code.google.com/p/pharo/issues/detail?id=3354 A fix is in PharoTaskForces

Nov. 29, 2010

[Pharo-project] Issue 3355 in pharo: Clean of RecentMessageList

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3355 by Benjamin.VanRyseghem.Pharo: Clean of RecentMessageList http://code.google.com/p/pharo/issues/detail?id=3355 A fix is in PharoTaskForces

Nov. 29, 2010

Re: [Pharo-project] <script language="smalltalk">

by csrabak＠bol.com.br

Em 28/11/2010 18:17, Igor Stasenko < siguctua(a)gmail.com > escreveu: > On 28 November 2010 19:41, wrote: > > Em 26/11/2010 16:25, Janko MivÅ¡ek < janko.mivsek(a)eranova.si > > >escreveu: > >> On 26. 11. 2010 18:20, csrabak(a)bol.com.br wrote: > Em 24/11/2010 > >> 11:50, Jan van de Sandt < jvdsandt(a)gmail.com > escreveu: > >> > >> >> A Smalltalk variant would use Smalltalk as the source language > >> >> instead of Java, the other parts of GWT can be reused. GWT is > >> >> open source (Apache 2.0 license). > >> > >> > I think we have first to evaluate to what audience/market are > >> > thinking of targeting this effort, then estimate the effort, in > >> > order to see if its worth it. > >> Specially we the web guys are very interested of such a beast, > >> because we need to develop more in more on the client side and in > >> JavaScript, which is a bit hard, because of our Smalltalk habits, > >> you know :) > > I _do_. However, it is also a major trend "in this vital > > industry"Â¹ the increase in restrictions on the client side leading > > a lot of developers to switch from Javascript (client side > > computing) to PHP (server side computing), for an example of a > > popular site which ostensibly writes it in its home page, look at: > > http://www.quantitativeskills.com/sisa/Â² > > same problem again: why doing things twice (write same things in > javascript on client side, and then rewrite same thing in PHP on > server side). Why, i am asking, why server and client side have to > use different languages? Why industry created such ridiculous > standards, which forcing us to use multiple languages depending on > environment? A CouchDB, for example, by default supports javascript > as a scripting language for views on server. This means, that > people to build their site & persistency, have to know only single > language - javascript. No PHP, no SQL and other rusty pieces of > technology. :) Perhaps my example has been misunderstood because I've put it in the fly without more explanation: the developers at SISA will _replace_ client side code with server side code and opted for PHP for whichever reason they felt to do so. Attempting to answer your question about "why server and client side have to use different languages?" is a subject for another thread, but in nutshell it can be explained by the "one size does not fit all" moto. What's "rusty" or "classic" or "proven" technology is in the beholder's eyes.... for a lot of 'gurus' Smalltalk is 'rusty' or 'antique' and belongs to museum. About "Why industry created..." the answer comes from marketting forces and attempts to 'lead' or 'gain market share'. > > > "Security" reasons plus less acquaintance with a newer technology > > would make this entry in the market very hard in today's > > environments. > > Perhaps what's _really_ needed is a good Javascript debugger? > > perhaps. And Self-like object's inspectors and explorers :) > [snipped] > > So, rephrasing my point above: except if we can produce those > > artifacts as a simple consequences of subclassing some objects in > > our environments and having a robust enough usable system, we > > rather consider carefully the use of our efforts in other areas > > where the fruits are hanging lower. > > Yes, i agree. Such plugin would require a big efforts to complete. > And while from tech side, we can foresee the benefits, from market > side, this is not obvious. Because niche is already filled by > javascript, which is also dynamic language and very powerful one. > What lacking, is a development environment for javascript, which can > be used to develop things as same pace as in smalltalk dev > environment. > Yes, like Eclipse ends up 'borrowing' a lot of features from Smalltalk environments and seems to those new wave of developers as genuine 'new' ideas, I think Smalltalk can at most be like a reference model for this. Regards, -- Cesar Rabak

Nov. 29, 2010

Re: [Pharo-project] Issue 3291 in pharo: Missing text field with completion

by pharo＠googlecode.com

Updates: Status: Fixed Comment #4 on issue 3291 by aplantec: Missing text field with completion http://code.google.com/p/pharo/issues/detail?id=3291 (No comment was entered for this change.)

Nov. 29, 2010