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

Re: [Pharo-project] removeSelector:

by StÃ©phane Ducasse

>> >>> Hello guys, >>> >>> regarding that comment of SmalltalkImage>>#removeSelector: is >>> >>> "Safely remove a selector from a class (or metaclass). If the >>> class or the method doesn't exist anymore, never mind and >>> answer nil. >>> This method should be used instead of 'Class removeSelector: >>> #method' to omit global class references." >>> >>> maybe Behavior>>#removeSelector: sould be deprecated ? >> >> not really >> >> in fact the other one is a hack. I imagine that this is more to make sure you write >> Smalltalk removeSelector: #foo instead of MyClass removeSelector: #foo. >> >> I'm not sure that this is used in fact. >> Stef >> > > Ok, so maybe we should add a comment in Behavior>>#removeSelector: to precise we should now use SmalltalkImage>>#removeSelector: instead ? no we should not use the one of SmalltalkImage. Stef

Nov. 24, 2010

Re: [Pharo-project] Symbol and Scanner

by StÃ©phane Ducasse

I see well your problem. We want to have symbol without getting with it the parser and compiler. three questions - can we package isLiteralSymbol: with compiler? - what are the senders? - else do we have an alternate implementation not relying on scanner? Stef > Hello, > > I wonder why the method isLiteralSymbol: is in the Scanner methodDict instead of the Symbol (or maybe String) one ? > > Moreover there is no reference to self or variable in this method ... > > > And due to this method, there is a dependence between Symbol and Scanner (and then the Compiler) > > > > Thank you for answering another one of my noob questions ^^ > > > > Ben >

Nov. 24, 2010

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

by csrabak＠bol.com.br

Em 24/11/2010 09:39, Janko MivÅ¡ek < janko.mivsek(a)eranova.si > escreveu: > I'm pretty sure that any plugin based solution will have a dead-end, > as all Smalltalk plugins so far had. There are just too many > browsers to support out there. FireFox, IE, Safari, Android, > Symbian, ... We are too small community to afford maintaining a > plugin on so many different browsers. I can agree with that, giving the past history of Smalltalk plugins. Besides, we've to accept a simple fact of life: for the end user there is not any apparent benefit of such additional plugin. Or, in other words: There is no compelling reason for an end user feel the need of an additional piece of SW to be installed in his/her computer, even harder if in a corporative environment where you have to get permits from sysadmins, etc. > Therefore I see the only viable long-term solution a Smalltalk on > top of JavaScript VM. Yes, I know, this is a very limited > environment for Smalltalk standards, but it is the least evil from > all choices we have. Except if this technology has something different from present state of art, this new layer (a.k.a. indirection) will have the single effect of bringing the smalltalk code to appear slower than 'native' javascript, without any benefit to the end user. > We actually have some effords done or underway already, like ST2JS, I understand these are a different beast: they 'translate' Smalltalk code into 'equivalent' javascript to be fed to the browsers. > Clamato, This is an hybrid, but basically tries to emulate some 'dialect' of Smalltalk in javascript. In the end, you need to master a nth language which is not nor javascript nor smalltalk anymore. Again, if the advantages of such approach are quickly accrued the additional effort to do so will deter the widespread of the technology. [snipped] my 0.019999.... -- Cesar Rabak

Nov. 24, 2010

Re: [Pharo-project] Issue 3283 in pharo: Symbol dependencie

by pharo＠googlecode.com

Comment #2 on issue 3283 by Benjamin.VanRyseghem.Pharo: Symbol dependencie http://code.google.com/p/pharo/issues/detail?id=3283 It's fixed (I hope). I've totally remodel dependencies between Symbol and Scanner : TypeTable is now in String isLiteralSymbol is in String too readFrom: does not depends of Scanner anymore neither does storeOn: I've added some tests (and recategorized some others), but if someone can have a look at SymbolTest>>#expectedBehavior, cause I do not know very well the expected behavior ^^ The changeSort is attached Attachments: SymbolClassReadFrom.2.cs 34.0 KB

Nov. 24, 2010

Re: [Pharo-project] is there an easy way to know the SmallInteger instances?

by Mariano Martinez Peck

On Tue, Nov 23, 2010 at 8:18 PM, <csrabak(a)bol.com.br> wrote: > Mariano, > > Your post has made think. . . for the final user this would put this method > farther from OO as possible, wouldn't it? > > which method and why ? ;)

Nov. 24, 2010

Re: [Pharo-project] Issue 3285 in pharo: Obsolete ConfigurationOfRFB

by pharo＠googlecode.com

Updates: Status: Accepted Labels: Type-MetacelloConfiguration Milestone-1.1 Milestone-1.2 Comment #1 on issue 3285 by rydier: Obsolete ConfigurationOfRFB http://code.google.com/p/pharo/issues/detail?id=3285 The orphaned version which does not load in Pharo, is the version on squeaksource: http://www.squeaksource.com/RFB.html Both the online book (which points to the metacello repository), and the seaside book, points to the version in http://source.lukas-renggli.ch/unsorted/. Latest versions of both Squeak and Pharo require 1@-1 to be written 1@ -1, which was fixed in .32 of RFB. So it is merely a case of the Configuration not being updated to use the latest version of the package.

Nov. 24, 2010

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

by Janko MivÅ¡ek

I'm pretty sure that any plugin based solution will have a dead-end, as all Smalltalk plugins so far had. There are just too many browsers to support out there. FireFox, IE, Safari, Android, Symbian, ... We are too small community to afford maintaining a plugin on so many different browsers. Therefore I see the only viable long-term solution a Smalltalk on top of JavaScript VM. Yes, I know, this is a very limited environment for Smalltalk standards, but it is the least evil from all choices we have. We actually have some effords done or underway already, like ST2JS, Clamato, also Seaside's JavaScript from Smalltalk way of programming. I think we should continue this way and, as I said, forget any plugin way. Best regards Janko On 23. 11. 2010 23:46, Torsten Bergmann wrote: >> How easy/hard to integrate smalltalk VM into browsers? It it feasible? > > You need to run as a plugin in the browser, so the VM has to be > in process (DLL on windows instead of exe for instance) > >> I know, there is (or was) a Squeak browser plugin. > > Yes there was/is a Squeak ActiveX control for InternetExplorer > and a Netscape plugin for NS compatible browsers. > Dont know about the maintenance state... > As you already said ... they are more like "applet providers" > in Java. AFAIK they are not interfacing with the scripting > engines of the browser. > >> While i thinking, that it would be cool to use smalltalk directly in >> pages, as javascript. > > That would mean to run on the client in the browser and mean to: > > - build a small downloadable VM as a plugin into the browser > since the plugin itself is browser dependent and OS dependent > you have to build one for each of the major browsers and OS's on the > market, > > Dont know about the other browsers but for Internet Explorer > you would have to implement the ActiveScripting Engine COM interfaces. > > This would mean you could then use it in any application that is an > ActiveX scripting host (like IE, Word, Windows Scripting shell, ...) > and you get the <script language="smalltalk"> for free in IE. > > For instance vbscript.dll and jscript.dll are done this way. > I think ActivePerl, ActivePython, ... from Activestate.com > are implemented similar. > > You also have to think about securing your VM since typically a > script executed in a webbrowser should not access files/clipboard/etc. > otherwise it would be easy to harm computers from a website. > > - build a small (kernel) image that provides basic functionality, > comes with the VM above and and accepts the scripts to run them > > - for the bare bone scripting part you should check out > "squeaksource.com/Sapphire" > > I'm sure it could be done but you would need time and good knowledge > of C/C++, Squeak VM creation, Scripting, ... > > Question left is why you want all this. Instead of Smalltalk you > can use JavaScript for the browser/client part of your app. > JavaScript is very dynamic and meanwhile supported and fast enough in nearly any browser.... > > Bye > T. > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Nov. 24, 2010

Re: [Pharo-project] Issue 3283 in pharo: Symbol dependencie

by pharo＠googlecode.com

Updates: Status: Started Comment #1 on issue 3283 by marcus.denker: Symbol dependencie http://code.google.com/p/pharo/issues/detail?id=3283 Nope... Symbol readFromString: '#''abc'''

Nov. 24, 2010

Re: [Pharo-project] Fwd: [Pharo-users] TestMock: a full featured mock testing framework now available in SqueakSource

by Dennis Schetinin

I'm aware of this idea. It is very interesting. Actually, I often meet this pattern in practice. But I don't see how it is connected with Mocks :) 2010/11/24 Tudor Girba <tudor.girba(a)gmail.com> > Given this discussion, I would like to encourage you to take a look at > Phexample by Adrian Kuhn and Niko Schwarz, based on previous work of Markus > Gaelli. The basic idea is that there is no distinction between setup and > tests. They are all examples, and examples are built on top of each other. > > Phexample is completely compatible with SUnit. It also comes with a fancier > API, but even if you would like to debate this API, I believe it is a nice > thing that we should look more closely into. > > Here are two examples checking an implementation of Stack. The first one > creates the stack and checks that it should be empty, and the second one > checks the pushing behavior: > > ForExampleStack>>shouldBeEmpty > | stack | > stack := Stack new. > stack isEmpty should beTrue. > stack size should = 0. > ^ stack > > ForExampleStack>>shouldPushElement > | stack | > stack := self given: #shouldBeEmpty. > stack push: 42. > stack isEmpty should not beTrue. > stack size should = 1. > stack top should = 42. > ^ stack > > More information can be found here: > > http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… > > You can get it by simply: > Gofer new > squeaksource: 'phexample'; > addPackage: 'Phexample'; > load > > > Cheers, > Doru > > > On 24 Nov 2010, at 08:28, laurent laffont wrote: > > > I agree with you Dennis. TDD practices are far ahead in Ruby / Java / > Python world. > > > > BUT IMHO can be a real cool neaty great platform for TDD because we have: > dynamic development. > > > > What I think we miss: > > - put a Mock framework in PharoCore - Mocks should be a standard tool > even for low-level stuff > > - introduce pragmas to declare tests / setUp / tearDown methods so I can > write > > > > AddressBookWithLaurentAndDennis>>createAddressBook > > <setUpTest> > > bla bla > > > > AddressBookWithLaurentAndDennis>>shouldHaveNumberOfContactsAnswersTwo > > <test> > > blabla > > > > > AddressBookWithLaurentAndDennis>>ifDennisRemovedNumberOfContactsShouldAnswersOne > > <test> > > bla bla > > > > > > > > - (harder) interface to / creation of an executable requirements / BDD > framework like Cucumber http://cukes.info/ > > > > Laurent > > > > > > On Wed, Nov 24, 2010 at 4:31 AM, Dennis Schetinin <chaetal(a)gmail.com> > wrote: > > As for me, I'm simply unable to establish smooth test-driven process > without Mocks. I think it does not depend on language at all. > > > > Without mocks I have to divide the task I have into smaller independent > parts. It's actually an up-front design. I can make a mistake (I usually > do); even worse it's often just impossible to accomplish because too many > subcomponents usually interact thoroughly and I simply don't know which one > to implement first :). So, without mocks I have to code bottom-up, from > details to general. This is unnatural and error-prone. > > > > With mocks I can start directly from the task I have. I get a use case > and write a test for the one. Creating the test I detect subcomponents > needed, understand how they should interact and document that in the same > test. As those subcomponents do not exist yet, I have to specify them and > their behavior right in the test (if I don't want to break the process I've > just started). That's why I really need mocks. Then I can take another use > case or implement one of the mocks I used as a real object and so on. Thus, > mocks allow me to go top-down and implement only the things I really need, > not the things I think I'll need. > > > > Are there other, maybe better, approaches? > > > > Concerning TDD popularityâ¦ I'm not sure TDD plays the role it should in > Smalltalk community. > > > > Messing with Smalltalk for about 7â8 years, I can't say I often see real > TDD code. About 50â70% (depending on Smalltalk dialect) of frameworks I use > have no tests at all. The rest often looks being tested a posteriori. > Perhaps, Pharo is the only exclusionâ¦ > > > > And if TDD is really popular and widely used, why do we have so much > regression bugs even in core subsystems even in commercial Smalltalks? > > > > Please, correct me if I'm wrong. > > > > 2010/11/23 laurent laffont <laurent.laffont(a)gmail.com> > > > > On Tue, Nov 23, 2010 at 5:39 PM, Luc Fabresse <luc.fabresse(a)gmail.com> > wrote: > > Hi Dennis, > > > > Yes, TDD is highly popular and encouraged in the Smalltalk community. > > And mocks are not necessary in most cases. > > > > > > Hi Luc, > > > > why Mocks are less necessary in Smalltalk than in other > (Ruby/Python/whatever...) languages ? Do you have some examples / link ? > > > > Sometimes I think a mocking library should be in PharoCore so I don't > need to write my own mocks..... > > > > > > Cheers, > > > > Laurent > > > > > > > > > > #Luc > > > > > > 2010/11/23 Dennis Schetinin <chaetal(a)gmail.com> > > > > How is it compared to Mocketry ( > http://www.squeaksource.com/Mocketry.html)? SMock? > > > > BTW, isn't TDD without mocks a bit incomplete? And is TDD popular among > smalltalkers actually? > > > > 2010/11/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > This is cool Anindya. I don't need mocks right now, but I will keep it in > mind! > > > > I cc'ed Pharo-dev mailing list. > > > > Cheers > > > > Mariano > > > > ---------- Forwarded message ---------- > > From: Anindya Haldar <anindya_haldar(a)yahoo.com> > > Date: Mon, Nov 22, 2010 at 10:11 AM > > Subject: [Pharo-users] TestMock: a full featured mock testing framework > now available in SqueakSource > > To: pharo-users(a)lists.gforge.inria.fr > > > > > > Dear Pharoers, > > > > TestMcok is a full featured mock based test framework that I am very glad > to contribute to the community. It is in squeaksource under the project name > TestMock. Please feel free to try it, and feedback will be greatly > appreciated. The wiki section includes a brief how-to guide with code > examples. > > > > Regards, > > Anindya Haldar > > > > > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > > > > > > > -- > > Dennis Schetinin > > > > > > > > > > > > -- > > Dennis Schetinin > > > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > -- Dennis Schetinin

Nov. 24, 2010

Re: [Pharo-project] rename a method programatically

by Cyrille Delaunay

If someone wants to know, this is the I'm doing it: refactoring := RenameMethodRefactoring renameMethod: #oldMethodMethod in: class to: #newMethod permutation: (#()). refactoring execute. 2010/11/24 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Ok, thank you :) > > 2010/11/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> On Wed, Nov 24, 2010 at 9:44 AM, Tudor Girba <tudor.girba(a)gmail.com>wrote: >> >>> I was also referring to a programatic solution :). Perhaps the name is >>> misleading, but RB is not the UI. RB is primarily the engine behind that >>> contains the logic of performing a refactoring. >>> >>> >> Exactlly. The UI can be OB-Refactory, or Gaucho, or just programatic. >> >> >>> Doru >>> >>> On 24 Nov 2010, at 09:17, Cyrille Delaunay wrote: >>> >>> > Indeed, in my case I would like to do that wihtout using UI. I want to >>> write a test in which I rename a method and see if the events emited have >>> been well-catched by RPackage. >>> > >>> > 2010/11/24 Igor Stasenko <siguctua(a)gmail.com> >>> > On 24 November 2010 02:00, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> > > Well, as long as you want to perform a refactoring I believe that RB >>> provides the API in question. >>> > > >>> > Yes, of course. But question was 'how to do that programmatically' , >>> > not using browser or other UI. >>> > >>> > > Doru >>> > > >>> > > >>> > > On 24 Nov 2010, at 00:52, Igor Stasenko wrote: >>> > > >>> > >> On 24 November 2010 01:43, Tudor Girba <tudor.girba(a)gmail.com> >>> wrote: >>> > >>> Definitely use the RB for any code transformations. >>> > >>> >>> > >> >>> > >> I don't think it's a good option for meta-programming. >>> > >> For meta-programming, basic interface in Behavior or >>> ClassDescription >>> > >> should be enough for manipulating >>> > >> with methods, without dependency from RB. >>> > >> Actually, RB then can use same API for manipulations. >>> > >> >>> > >>> Cheers, >>> > >>> Doru >>> > >>> >>> > >>> >>> > >>> On 23 Nov 2010, at 19:01, Mariano Martinez Peck wrote: >>> > >>> >>> > >>>> Cyrille I don't know why you need that but take into account that >>> RB split their packages even more in the last months. So maybe it is easier >>> for you to directly use RB and load with your code, the RB core or the >>> specific package that you need. Mostly if you need some other similar >>> functionalities. >>> > >>>> >>> > >>>> Cheers >>> > >>>> >>> > >>>> Mariano >>> > >>>> >>> > >>>> On Tue, Nov 23, 2010 at 6:56 PM, jaayer <jaayer(a)zoho.com> wrote: >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> ---- On Tue, 23 Nov 2010 05:17:05 -0800 Cyrille Delaunay wrote >>> ---- >>> > >>>> >>> > >>>>> Hello, >>> > >>>>> >>> > >>>>> I would like to know how I can rename a method programatically >>> and safelly (without missing to raise any event that has to be raised) >>> > >>>>> >>> > >>>> >>> > >>>> I don't believe there is any simple way to do this. >>> > >>>> >>> > >>>> Basically, to rename a method you have to remove it first and >>> compile into its class a new method containing the same source code but with >>> a different selector at the beginning. This is how the refactory browser >>> does it when you select "rename" from the "refactor method" menu. If anyone >>> knows of a better way, I would be interested to hear it. >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>> >>> > >>> -- >>> > >>> www.tudorgirba.com >>> > >>> >>> > >>> "To lead is not to demand things, it is to make them happen." >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >> >>> > >> >>> > >> >>> > >> -- >>> > >> Best regards, >>> > >> Igor Stasenko AKA sig. >>> > >> >>> > > >>> > > -- >>> > > www.tudorgirba.com >>> > > >>> > > "Not knowing how to do something is not an argument for how it cannot >>> be done." >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko AKA sig. >>> > >>> > >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem >>> understanding." >>> >>> >>> >>> >>> >> >

Nov. 24, 2010