- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by Dennis Schetinin

I hope you are serious :) I don't know how to write a small tutorial, and I have no time to write a long one â¦Actually, I have been writing something like that (not for Smalltalkers but for my students) for a couple of years alreadyâ¦ in Russian and really, really slow :( -- Best regards, Dennis Schetinin 2013/6/6 askoh <askoh(a)askoh.com> > Dennis: > > You seem to see more in TDD than most people. Can you write a small > tutorial > that illustrates what you think Smalltalkers need to see in TDD? I do think > Smalltalk is missing something in it evolution. > > Thanks, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Pharo-dev-Necessity-of-TDD-with-Smalltalk-tp4691867p4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 7, 2013

Re: [Pharo-dev] 30181 Kernel package Dirty

by Sean P. DeNigris

Damien Cassou wrote > which repository are you comparing against? You must always compare > against the Pharo30 repository (not Pharo30Inbox) Hmm... I can't reproduce either. Maybe that was the problem - long day yesterday :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/30181-Kernel-package-Dirty-tp4692004p4692166.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 7, 2013

SmalltalkHub misleading stats?

by Mariano Martinez Peck

Hi guys. In my own instance of shub that I am running, the number of "packages uploaded" shown in the home of smalltalkhub looked like 10k, while I only have around 10 packages. In public smalltalkhub it says 60997. So I wonder....what they actually are? can they actually be package VERSIONS uploaded and not just packages? Thanks! -- Mariano http://marianopeck.wordpress.com

June 7, 2013

Re: [Pharo-dev] Please review Cases 10785 and 10314

by Damien Cassou

On Thu, Jun 6, 2013 at 5:47 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 10785 Auto-complete protocol renaming > https://pharo.fogbugz.com/f/cases/10785/Auto-complete-protocol-renaming > > 10314 Debugger: create better argument names > https://pharo.fogbugz.com/f/cases/10314/Debugger-create-better-argument-nam… I reviewed both. They are ready for inclusion. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 7, 2013

[update 3.0] #30184

by Marcus Denker

30184 ----- 10857 Add new public API to old compiler https://pharo.fogbugz.com/f/cases/10857 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.477.diff

June 7, 2013

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by Dennis Schetinin

As for me, the StringCalculator kata is a very good (or better to say nearly perfect) demo of a classic TDD approach: small and fast steps, live objectsâ¦ really nice! Though I see (feel?) some issuesâ¦ mostly about factoring-out new classes without tests (yes, that was refactoringâ¦ but still), I believe, that's beyond classic approach and only top-down TDD with mocks may help to keep TDD pure here. (I've scheduled a task for detailed exploration of how mocks can be used here to provide "seamless" TDD in this case.) So, this screencast is a great lesson on TDD in Smalltalk. -- Best regards, Dennis Schetinin 2013/6/7 Rafael Luque <rafael.luque.leiva(a)gmail.com> > Hi Dennis, > > What do you think about the approach shown in this screencast: > http://www.pharocasts.com/2011/02/stringcalculator-kata.html ? > > I'm far away from being an Smalltalk developer, but I tried to show a TDD > process to solve this simple kata. > > Rafael Luque > > > 2013/6/7 Dennis Schetinin <chaetal(a)gmail.com> > >> I don't remember exactly where and when, but I think we've discussed the >> Laser Game tutorial already. I told this before, and I (after reviewing the >> tutorial again) should repeat it again: actually, this tutorial doesn't >> show TDD. I can explain my opinion in detail if someone's interested, but >> in general, that's simply an up-front design approach with some automatic >> testing. It's not even "Test-First" approach most of time. >> >> Disclaimer: I don't mean the tutorial and/or the design approach used >> there are bad. I like this tutorial. It's really very good: it shows many >> aspects for Smalltalk programing, it shows how to use debugger and >> inspectors properly. I borrowed many ideas from there for my Smalltalk >> programming courseâ¦ It's just not TDD, not "pure" TDD at least. >> >> >> >> -- >> >> Best regards, >> >> >> Dennis Schetinin >> >> >> 2013/6/7 <btc(a)openinworld.com> >> >> Paul Davidowitz wrote: >>> >>>> It seems to me that a big reason for developing via writing tests first >>>> (Test Driven Development) is that the tests serve as a debugging tool -- >>>> if a test breaks, then the last piece of (non-test) code that change is >>>> likely the culprit. But with the powerful debugging environment that >>>> comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >>>> in the Ruby camp perhaps for a reason). After all, writing and >>>> re-writing the tests becomes quite a non-trivial chore (not to mention >>>> that the tests themselves could be buggy). So my question: Is it ok in >>>> Smalltalk to write tests afterwards? Is it even perhaps recommended? >>>> >>>> - Paul >>>> >>>> >>>> >>>> >>> Actually some Smalltalk'ers consider the debugger a major facilitator of >>> TDD by mostly coding from within the debugger. >>> 1. Before writing any application code, write a test. >>> 2. Execute that test straight away. Of course it fails because you >>> haven't written any application code. >>> 3. Up comes the debugger - now "from within the debugger" add the >>> application code needed to satisfy the test. >>> 4. Repeat. >>> >>> A good demonstration of this is Stephan Wessels' Laser Game tutorial [1] >>> (but you'll temporarily need to revert to Squeak 3.9 to do it) >>> cheers -ben >>> >>> >>> >> >

June 7, 2013

[update 3.0] #30183

by Marcus Denker

30183 ----- 10813 Update Opal to latest version in image https://pharo.fogbugz.com/f/cases/10813 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke…

June 7, 2013

Re: [Pharo-dev] I cannot merge 10828 and 10830 because the system does not find

by Marcus Denker

On Jun 7, 2013, at 12:17 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > no idea :( > > you can try copying it into inbox, but this is weird. > I had the same problemâ¦ I copied it to the inbox, no change. What works is to once select the package so that it gets copied to the local cache. This is very odd. > Esteban > > On Jun 7, 2013, at 11:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: I cannot merge 10828 and 10830 because the system does not find >>> Date: June 7, 2013 11:49:47 AM GMT+02:00 >>> To: Esteban Lorenzano <estebanlm(a)gmail.com> >>> >>> Morphic-Base-EstebanLorenzano.3 >>> I do not understand why >> >> especially since the file is in main. >> >>> >>> Stef >> >

June 7, 2013

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by Henrik Johansen

On Jun 7, 2013, at 11:34 AM, Camille Teruel wrote: > On 7 juin 2013, at 11:19, Pharo Issue Tracker wrote: > >> A FogBugz case was edited by Stephane Ducasse. >> >> Case ID: 10840 >> Title: WeakSet>>#size utterly broken >> Status: Resolved (Fix Review Needed) >> Category: Bug >> Project: Collection >> Area: Misc >> Priority: 3 - Must Fix >> Milestone: Pharo3.0: 30/03/2014 >> Assigned To: Camille Teruel >> >> URL: https://pharo.fogbugz.com/f/cases/10840 >> >> Last message: >> Please can you send a mail to the mailing-list so that we all discuss this problems. > > Hello everyone, > > WeakSet>>#size is broken as demonstrated by the following snippet: > > set := WeakSet new. > set add: Object new. > Smalltalk garbageCollect. > set size. "answers 1 instead of 0" > > That is because a WeakSet has no mean to know when its items get garbage collected, and thus the tally cannot be updated. > So we need to override #size in Weak, I propose: > size > | counter | > counter := 0. > self do: [ :e | counter := counter + 1 ]. > ^ counter > But that it rather inefficient for such a simple query. > Any proposition? I would leave size as is, with a comment that by default, it should not be trusted. Then provide an alternative WeakSet constructor, which returns an instance which registers objects added to it for finalization, with a finalizing action basically doing size := size - 1. One complication is to make sure to detect and handle the case where object being added is already registered for finalization. I think the current size-inaccurate should still be the default, as the alternate will (for obvious reasons) sacrifice speed of normal ops for a fast, more* accurate size, and as such should only be used when that is important. Cheers, Henry * In the sense that, I'm not sure what GC actions actually trigger the finalization processâ¦ scavenging? Either way higher-than-finalization priority threads can still strictly speaking return inaccurate sizes

June 7, 2013

Class comments... we want them but, ... hard to convince the system at this point in time

by phil＠highoctane.be

https://pharo.fogbugz.com/default.asp?10861 Still, this happens when doing a mcz load. Wondering... Phil

June 7, 2013