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

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by Stan Shepherd

laurent laffont wrote: > > 2010/1/15 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> 2010/1/15 laurent laffont <laurent.laffont(a)gmail.com> >> >>> >>>> which I converted in a workspace. I used ShoutWorkspace for that >>>> because >>>> you have colors and is nicer :) >>>> >>> >>> Totally stupid question: how can I change the text inside a >>> ShoutWorkspace >>> once it's opened ? >>> >>> >> >> Maybe my answer is more stupid than your question ;) >> >> I think I don't understand. >> >> > To display each lesson I use PluggableTextMorph#setText: > > (You can take a look at LessonView#open and LessonView#showLesson) > > I haven't found a such method in Workspace. > > On squeaksource I have committed a version which use PluggableShoutMorph, > so > now I have syntax highlighting. > > Cheers, > > Laurent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Did you mean something like (Workspace new contents: ('red text' asText addAttribute: (TextColor color: Color green)); embeddedInMorphicWindowLabeled: 'Welcome to Pharo') position: 100@100 ; width: 200; height: 500; openInWorld ...? Stan -- View this message in context: http://n2.nabble.com/Smalltalk-interactive-tutorial-in-good-English-tp43993… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 15, 2010

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by laurent laffont

Thank you ! Laurent On Fri, Jan 15, 2010 at 10:18 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > hey this is really neat! > > I can offer you some corrections or perhaps suggestions for better > phrasing. just my native 2p if it helps. > > As a general comment, i know it would be more work, if you could get > some emphasis e.g bold, italics it would really make the expressions > and names of classes or methods stand out. > > ---Welcome--- > I suppose you have called me to learn Smalltalk. > --> > You must want me to help you learn Smalltalk! > > ---Doing vs printing--- > You've just executed a Smalltalk instruction > --> > You've just executed a Smalltalk expression > > > ---Doing vs printing 2--- > It's a Do It which print the result > --> > It's a Do It which prints the result > > > ---basic types numbers--- > you know how to execute Smalltalk code > --> > you now know how to execute Smalltalk code > > ---basic types characters--- > A Character can be instanciated > --> > A Character can be instantiated > > --basic types string--- > Use single quotes to create a String instance > --> > Use single quotes to create a String. > > ---basic types dynamic array--- > Dynamic Array are created at execution time: > --> > Dynamic Arrays are created at execution time: > > > ---unary messages--- > Unary messages have the following form: > anObject aMethod name > --> > anObject aMethodName > > --keyword messages-- > The message is between:and: sent to Number object > --> > The message is between:and: sent to the Number 4 > > ---message syntax: execution order--- > Between similar messages, expressions are executed from left to right > --> > Between messages of similar precedence, expressions are executed from > left to right > > ---parentheses--- > Use parentheses to change order > --> > Use parentheses to change order of evaluation > > ---mathematical precedence--- > A message does not know mathematical precedence. Simplicity has a price :) > --> > (rephrase ?) > Traditional precedence rules from mathematics do not follow in > Smalltalk. The simplicity has a price ;) > It might surprise you that precedence rules you know from mathematics > do not apply here. This has a price as you can see... > > ---conditionals--- > Conditionals are just message sent to Boolean objects > --> > Conditionals are just messages sent to Boolean objects > > ---loops--- > Loops are messages send to collections, high-level iterators > --> > Loops are messages sent to collections, high-level iterators > > ---iterators--- > Here we want to print all the numbers of the Transcript (a console) > --> > Here we want to print all the numbers on the Transcript (a console) > > ---() vs []--- > --> > I know what you are trying to articulate here, but this page doesn't > really work since your 'annotation' is not syntactic and therefore > your learning style breaks. > pehaps have a think about this slide > > cheers > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] Smalltalk interactive tutorial in good English

by laurent laffont

2010/1/15 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/1/15 laurent laffont <laurent.laffont(a)gmail.com> > >> >>> which I converted in a workspace. I used ShoutWorkspace for that because >>> you have colors and is nicer :) >>> >> >> Totally stupid question: how can I change the text inside a ShoutWorkspace >> once it's opened ? >> >> > > Maybe my answer is more stupid than your question ;) > > I think I don't understand. > > To display each lesson I use PluggableTextMorph#setText: (You can take a look at LessonView#open and LessonView#showLesson) I haven't found a such method in Workspace. On squeaksource I have committed a version which use PluggableShoutMorph, so now I have syntax highlighting. Cheers, Laurent

Jan. 15, 2010

Re: [Pharo-project] Toyota like process for 1.1

by Adrian Lienhard

+1 On Jan 15, 2010, at 22:55 , Michael Roberts wrote: > i would prefer we fix them as soon as possible. Look at the effort at > the end of 1.0. It can be really sad to try and fix all the tests at > once. Having a green baseline is much easier to manage. Even if we > can't fix the bugs immediately, we should at least discuss them and > comment them on the tracker. Then at least we can easily discuss what > code has just gone into the image. Otherwise it is somewhat of an > archeology exercice going through 100s of old updates. this will of > course be easier with the continuous integration work. > > Now of course, some bugs are *really* hard. e.g decompiler bugs. > Debugger bugs. These would be great to attack with sessions & > sprints. > > cheers, > Mike > > On Fri, Jan 15, 2010 at 9:48 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> may be I'm wrong but I have the impression that fixing tests as soon as they are broken >> in the Unstable branch could be better. Now doing that may stall our energy. >> So what do you think? >> May be an alternate process is to make progress and to do green test session from time to time. >> >> Stef >> _______________________________________________ >> 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

Jan. 15, 2010

Re: [Pharo-project] mac vm version number on pharo-project.org/pharo-download page

by Adrian Lienhard

I fixed it. Cheers, Adrian On Jan 15, 2010, at 22:22 , John M McIntosh wrote: > I noticed the mac vm version number on pharo-project.org/pharo-download page is wrong, it says 4.2.2b2 > but actually it's 4.2.2b1 > > If someone can correct it, that would be great and it will keep me from thinking I've managed to misplace a VM somewhere... > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 15, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> > > On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: > > > > On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > >> yes it has overrides ... >> >> that's because as far as I know, there's no keyboard shortcut management >> facility >> in Pharo. If there was one, I suppose Algernon and WorkingSet would >> coexist. >> > > > So...all your overrides are due to the shortcuts? I think it is not fear > to "forbid" a package to be included in a Dev image if we don't provide from > the core a way to manage shortcuts. So: > > 1) Or we let this projects to be installed in the Dev image > > 2) We fix the problem with the shortcuts. > > Romain: can you tell us where exactly the problem is ? maybe someone can > give you a hand. > > > > Taking a look at that, there are 2 overrides in WorkingSet > How did you detect that ? > > PasteupMorph>>keystrokeInWorld: > but the diff is the same with my default version! So it can be removed > > HandMorph>>sendKeyboardEvent: > which is the real conflicting method > > Looking at it, there are 3 different versions, the default one, one from > WorkingSet and one from Algernon. On the plus sign, it's quite easy to merge > the last two and make WorkingSet works together with Algernon. > > > But the one from Algernon is actually the worst way to patch things, > because it is all in a changeset which is encoded in binary format (see > ConfigurationOfAlgernons>>multipleFocusHolderCs :( > > It adds an instance variable to HandMorph and overrides two methods in > HandMorph. Of course you cant see it at first since these are hidden in the > binary changeset :( > > '''From Squeak3.7gamma of ''''17 July 2004'''' [latest update: #5985] on 9 > August 2004 at 7:56:10 pm''! > "Change Set: MultipleFocusHolder-hpt > Date: 9 August 2004 > Author: Hernan Tylim > > This changesets does the simplest modifications to HandMorph for it to > support various focus holders. > > The important changes are: > > * addiionalKeyboardFocuses instance variable was added with its getter and > setter methods. > > * HandMorph>>sendKeyboardEvent: was changed to traverse the list of > keyboard focus holders and call HandMorph>>sendEvent:focus:clear: to each > one of them. > > * HandMorph>>sendEvent:focus:clear: was changed to preserve the > ''wasHandled'' status of the event, before that info were lost because the > Event instance were copied before passed to the Morph. > "! > > The comment itself is misleading, it overrides sendFocusEvent:to:clear:, > not sendEvent:focus:clear: > > Impressive. You should be a detective :) > I feel much less keen to include Algernon now that I have seen that. > > Yes, me too. Completely. > > > > > > Cheers > > Mariano > > > >> >> Romain >> >> >> On Jan 15, 2010, at 6:49 AM, Damien Cassou wrote: >> >> > 2010/1/15 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> Thanks Damien. I did that, run the load of both projects but none of >> them >> >> warn me. >> >> >> >> Are you sure they have overrides? >> > >> > I'm sure that WorkingSet has overrides, my detection code is probably >> > not correct. >> > >> > -- >> > Damien Cassou >> > http://damiencassou.seasidehosting.st >> > >> > "Lambdas are relegated to relative obscurity until Java makes them >> > popular by not having them." James Iry >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> >> _______________________________________________ >> 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 > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] Toyota like process for 1.1

by Michael Roberts

i would prefer we fix them as soon as possible. Look at the effort at the end of 1.0. It can be really sad to try and fix all the tests at once. Having a green baseline is much easier to manage. Even if we can't fix the bugs immediately, we should at least discuss them and comment them on the tracker. Then at least we can easily discuss what code has just gone into the image. Otherwise it is somewhat of an archeology exercice going through 100s of old updates. this will of course be easier with the continuous integration work. Now of course, some bugs are *really* hard. e.g decompiler bugs. Debugger bugs. These would be great to attack with sessions & sprints. cheers, Mike On Fri, Jan 15, 2010 at 9:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > may be I'm wrong but I have the impression that fixing tests as soon as they are broken > in the Unstable branch could be better. Now doing that may stall our energy. > So what do you think? > May be an alternate process is to make progress and to do green test session from time to time. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

[Pharo-project] Toyota like process for 1.1

by StÃ©phane Ducasse

Hi guys may be I'm wrong but I have the impression that fixing tests as soon as they are broken in the Unstable branch could be better. Now doing that may stall our energy. So what do you think? May be an alternate process is to make progress and to do green test session from time to time. Stef

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Nicolas Cellier

2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok I imagine that this is this change. > Yes, comments are such good things ! You shall prefer to have a proceedable exception in pharo and keep an explicit message... > Name: Monticello-nice.342 > Author: nice > Time: 27 December 2009, 9:03:54 am > UUID: ead29222-29d3-421a-8d89-08d667014c1c > Ancestors: Monticello-bf.341 > > change #findSnapshotWithVersionInfo: to silently ignore a missing ancestor rather than sending #snapshot to nil. > This happens for example when merging Pharo/CollectionTests. > Don't know if this is the good strategy though (maybe a notification could be signalled) > > + Cosmetic: move or remove a few temps inside closures > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Simon Denier

On 15 janv. 2010, at 22:16, StÃ©phane Ducasse wrote: >> >> It adds an instance variable to HandMorph and overrides two methods in HandMorph. Of course you cant see it at first since these are hidden in the binary changeset :( > > what is a binary changeset > I just coined the term :) It looks like that in the method: #(39 70 114 111 109 32 83 113 117 101 97 .... and much more bytes until.... 101 108 39 33 13) asByteArray asString -- Simon

Jan. 15, 2010