- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Contributors page (was little pictures of you)

by StÃ©phane Ducasse

>> >>> Obviously, I'm not talking about igor and other people with a lot more >>> knowledgment than me, only >>> commenting my own experience. And by other hand, if I use Pharo, I >>> feel the need of help on the >>> development, it's the open source spirit. >> >> Thanks. >> I think that taking care of a stuff that can help you for your projects is important in general. >> For example people can ask themselves: why stef is spending so much time on ESUG (because this is a lot of time >> and energy), well simple, when I discovered Smalltalk I went to the conf and it was dying (both the language >> and the conference) so I thought either I complain: "oh my language is dying sniff sniff", "when I was young there >> were a cool conference". Or I do something to try to make the future better. >> Simple is n't it? Something you do not know if it will work but trying is the only chance we got. >> > > Yes, it is. > There is a little people who put as much energy into it (smalltalk in > general) as you do, > totally freely, without any business agenda. > I can only applaud your efforts and wish you success. > And, please continue :) Thanks. Fun and love is my business agenda even if sometimes I have my own doubts....

Aug. 16, 2010

Re: [Pharo-project] Ideas of AutomaticMethodCategorizer ???

by StÃ©phane Ducasse

did you check is there is a safe guard when the category start with *? ?Stef > > Hi folks...while browsing AutomaticMethodCategorizer I found the place where the rules are defined. It is cool becuase we can add the rules we want. I am all ears. > > yes I would really like to have consistent categories. > Now we should pay attention that the automaticmethodcategory does not do anythin when the category is * something. > > Stef > > > > For now, it is doing this: > > > > > > defaultCategorizationRules > > > > "The order is relevant, the categorizer uses the first rule matching - DF" > > > > ^OrderedCollection new > > add: MethodCategorizationRule forAccessors; > > add: (MethodCategorizationRule whenSelectorMatches: 'initialize*' categorizeIn: #initialization); > #initialize > > > add: (MethodCategorizationRule whenSelectorMatches: 'is*' categorizeIn: #testing); > > add: (MethodCategorizationRule whenSelectorMatches: 'has*' categorizeIn: #testing); > > add: (MethodCategorizationRule whenSelectorMatches: '=' categorizeIn: #comparing); > > add: (MethodCategorizationRule whenSelectorMatches: 'hash' categorizeIn: #comparing); > > add: (MethodCategorizationRule whenSelectorMatches: 'default*' categorizeIn: #defaults); > > add: (MethodCategorizationRule whenSelectorMatches: 'printOn:' categorizeIn: #printing); > > add: (MethodCategorizationRule whenSelectorMatches: 'accept:' categorizeIn: #'visitor accepting'); > > add: (MethodCategorizationRule whenSelectorMatches: 'visit*:' categorizeIn: #visiting); > > add: (MethodCategorizationRule whenSelectorMatches: 'value' categorizeIn: #evaluating); > > add: (MethodCategorizationRule > > whenSelectorMatches: 'test*' > > andClassInheritsFrom: TestCase > > categorizeIn: #tests); > > add: MethodCategorizationRule usingMostUsedCategoryInSuperClasses; > > add: MethodCategorizationRule usingMostUsedCategoryInImage; > > yourself > > > > > > One important thing I forgot to say is that the order is important here. Notice that the pattern rules are first and then the rules for the most used categories...this means that for example printOn: will be always in 'printing'. However, in the system most printOn: could be in 'print' category... > > So it is important what you want more...if specific patterns or maintain consistency with what you have in the system... > > cheers > > mariano > > > > > > > > We should improve this guy.... ideas to add/change? > > > > Cheers > > > > Mariano > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2010

[Pharo-project] Help for compiler needed

by StÃ©phane Ducasse

Hi guys I'm busy and not really friend with the squeak compiler so if some of you want to help this is welcome. http://code.google.com/p/pharo/issues/detail?id=2818 Stef > Hi StÃ©ph, > > you should harvest at least the compiler and explainer ones of these. > > cheers > Eliot > > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: Sun, Aug 15, 2010 at 4:55 PM > Subject: [squeak-dev] Daily Commit Log > To: squeak-dev(a)lists.squeakfoundation.org > > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003597.html > > Name: Compiler-eem.155 > Ancestors: Compiler-eem.154 > > Fix comment and computation of error temp push in > BytecodeAgnosticMethodNode>>generate:. Remove > a couple of unused methods. > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003598.html > > Name: ST80-eem.117 > Ancestors: ST80-nice.116 > > Fix explainer for block args & temps > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003599.html > > Name: Morphic-eem.460 > Ancestors: Morphic-ar.459 > > Fix explainer for block args & temps > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003600.html > > Name: Tools-eem.256 > Ancestors: Tools-cbr.255 > > Fix multi-window menu labelling for unselected windows > (old code broke if system organization changed). > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003601.html > > Name: Tools-eem.257 > Ancestors: Tools-eem.256 > > Fix select unchanged definitions for variableSubclass: class defs > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003602.html > > Name: Tools-eem.258 > Ancestors: Tools-eem.257 > > Don't cache the debugger's debuggerMap, its not safe. > Add preference for and support of opening a debugger for an error > in a background process when the UI process is busy. > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003603.html > > Name: Kernel-eem.477 > Ancestors: Kernel-dtl.476 > > Add a followingBytecode to InstructionStream, e.g. > SystemNavigation default browseAllSelect: > [:m| | is | > m isQuick not > and: [is := InstructionStream on: m. > is scanFor: [:b| b = 16r8F > and: [is secondByte ~= 0 > and: [is followingBytecode = 115]]]]] > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003604.html > > Name: Compiler-eem.156 > Ancestors: Compiler-eem.155 > > The addition needed by the new explainTemp: code. > (Humble mumble, I forgot to add this and hence mention > that Morphic-eem.460 & ST80-eem.117 need this method) > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003605.html > > Name: Tests-eem.89 > Ancestors: Tests-ar.88 > > Tests to check that whether a block is optimized or not a > block-local temp should be nil at the start of each > evaluation of the block. > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003606.html > > Name: Compiler-eem.157 > Ancestors: Compiler-eem.156 > > Log class def on declare inst and class var. > Fix typo in ParseNodeVisitor>>visitMessageNode: > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003607.html > > Name: System-eem.356 > Ancestors: System-ar.355 > > Fix ChangeRecord>>methodClass so that class comment > change defs can be replayed. > > ============================================= > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003608.html > > Name: Compiler-eem.159 > Ancestors: Compiler-eem.157 > > Declare temps at the minimum enclosing block scope. Requires > deferring temp declarations until after the parse has completed. > So introduces an UndeclaredVariableNode type to stand in until > parse completes. VariableScopeFinder visitor finds scopes. > > Fix Parser>>removeUnusedTemps after a declare temps. > removeUnusedTemps cannot use encodeVariable: to lookup > out-of-scope temps; these will cause undeclared: sends within > encodeVariable:. > > Fix Parser>>#parse:class:category:noPattern:context:notifying:ifFail:'s > selection of the stream after ReparseAfterSourceEditing. It must > grab the selectionInterval from the requestor's string, not the entire > string. > > Resolve the ambiguous time stamp (almost certainly my fault) in > Compiler>>#from:class:classified:context:notifying: between our > rep and trunk's rep by neatening method. > > =============================================

Aug. 16, 2010

Re: [Pharo-project] whileTrue: implementation

by Hernan Wilkinson

I agree, at least change the comment... Changing the implementation would be a winner too :-) Hernan PS: I meant "purposes" not "porpoises" in the original mail :-) Thanks Sean to point me that out :-) 2010/8/16 Eliot Miranda <eliot.miranda(a)gmail.com> > > > On Mon, Aug 16, 2010 at 11:28 AM, Randal L. Schwartz < > merlyn(a)stonehenge.com> wrote: > >> >>>>> "Hernan" == Hernan Wilkinson <hernan.wilkinson(a)gmail.com> writes: >> >> >> Hernan> whileTrue: aBlock >> >> Hernan> self value ifTrue: [ >> Hernan> aBlock value. >> Hernan> thisContext restart ] >> >> That's an interesting implementation, but the current implementation >> is clean, and is there only because #perform: has to be able to do it. >> > > Forgive me for being so blunt but IMO the current implementation is a crok. > It can't possibly work in the absence of the inlining optimization in > MessageNode: > whileTrue: aBlock > "Ordinarily compiled in-line, and therefore not overridable. > This is in case the message is sent to other than a literal block. > Evaluate the argument, aBlock, as long as the value of the receiver is > true." > > ^ [self value] whileTrue: [aBlock value] > > I stupidly forgot to change it in BlockClosure. The following /can/ work > without inlining (and can work as well as the inlined version if the > compiler implements tail-recursion elimination): > > whileTrue: aBlock > "Ordinarily compiled in-line, and therefore not overridable. > This is in case the message is sent to other than a literal block. > Evaluate the argument, aBlock, as long as the value of the receiver is > true." > > ^self value ifTrue: > [aBlock value. > self whileTrue: aBlock] > > BTW here's the VisualWorks 7.7 method. For me it's a little too clever. > > whileFalse: aBlock > "Evaluate the argument, aBlock, as long as the value of the receiver is > false." > > ^self value > ifFalse: > [aBlock value. > [self value] whileFalse: [aBlock value]] > > "This method is inlined if both the receiver and the argument are literal > blocks. In all other cases, the code above is run. Note that the code > above is defined recursively. However, to avoid actually building an > activation record each time this method is invoked recursively, we have > used the '[...] whileFalse: [..]' form in the last line, rather than the > more > concise 'self whileFalse: aBlock'. Using literal blocks for both the > receiver > and the argument allows the compiler to inline #whileFalse:, which (in the > absence of type inferencing) could not be done if we were to use > 'self whileFalse: aBlock'." > > but it's accurate and does the job of turning > | a b | > a := [i <= j]. > b := [i := i + 1]. > a whileTrue: b > into an iterative execution. > > So at the very least we should improve the comment in whileTrue: and > whileFalse: to point to the compiler optimization in MessageNode and IMO the > VisualWorks implementation is the best compromise between clarity and > honesty given the lack of tail-recursion elimination. > > 2Â¢ > > best, > Eliot > > > >> Maybe this definition could be added as a comment to the method though, >> to show how you would do it *if* it wasn't inlined. > > >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >> 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside >> discussion >> >> _______________________________________________ >> 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 > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 16, 2010

Re: [Pharo-project] whileTrue: implementation

by Eliot Miranda

On Mon, Aug 16, 2010 at 11:28 AM, Randal L. Schwartz <merlyn(a)stonehenge.com>wrote: > >>>>> "Hernan" == Hernan Wilkinson <hernan.wilkinson(a)gmail.com> writes: > > > Hernan> whileTrue: aBlock > > Hernan> self value ifTrue: [ > Hernan> aBlock value. > Hernan> thisContext restart ] > > That's an interesting implementation, but the current implementation > is clean, and is there only because #perform: has to be able to do it. > Forgive me for being so blunt but IMO the current implementation is a crok. It can't possibly work in the absence of the inlining optimization in MessageNode: whileTrue: aBlock "Ordinarily compiled in-line, and therefore not overridable. This is in case the message is sent to other than a literal block. Evaluate the argument, aBlock, as long as the value of the receiver is true." ^ [self value] whileTrue: [aBlock value] I stupidly forgot to change it in BlockClosure. The following /can/ work without inlining (and can work as well as the inlined version if the compiler implements tail-recursion elimination): whileTrue: aBlock "Ordinarily compiled in-line, and therefore not overridable. This is in case the message is sent to other than a literal block. Evaluate the argument, aBlock, as long as the value of the receiver is true." ^self value ifTrue: [aBlock value. self whileTrue: aBlock] BTW here's the VisualWorks 7.7 method. For me it's a little too clever. whileFalse: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is false." ^self value ifFalse: [aBlock value. [self value] whileFalse: [aBlock value]] "This method is inlined if both the receiver and the argument are literal blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileFalse: [..]' form in the last line, rather than the more concise 'self whileFalse: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileFalse:, which (in the absence of type inferencing) could not be done if we were to use 'self whileFalse: aBlock'." but it's accurate and does the job of turning | a b | a := [i <= j]. b := [i := i + 1]. a whileTrue: b into an iterative execution. So at the very least we should improve the comment in whileTrue: and whileFalse: to point to the compiler optimization in MessageNode and IMO the VisualWorks implementation is the best compromise between clarity and honesty given the lack of tail-recursion elimination. 2Â¢ best, Eliot > Maybe this definition could be added as a comment to the method though, > to show how you would do it *if* it wasn't inlined. > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside > discussion > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2010

Re: [Pharo-project] [Pharo-users] [SPAM] Pharocasts: Display Picasa photos

by laurent laffont

On Mon, Aug 16, 2010 at 5:41 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > > laurent laffont wrote: > > > > Thank you all ! I've tried to make a "Why Pharo is different" screencast, > > I'm pleased that it seems to work :) > > > These screencasts are *priceless!!!* Actually, they're free :D Thanks. Laurent > "Programming with live objects" rocked > my world when I first started with Smalltalk - it was like a child learning > how to walk by seeing someone walking. Oh, and the best part is that you > can so quickly get to any part of it via rewind/fast-forward - very > helpful! > > > laurent laffont wrote: > > > > If you have the courage to put these comments on pharocasts itself (even > > to > > say it's crap, just tell why), I will be very grateful ! (and it shows > > that > > the community is here) > > > Done. And thanks for asking, I didn't even think of it :) > -- > View this message in context: > http://forum.world.st/Pharocasts-Display-Picasa-photos-tp2326226p2327042.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2010

Re: [Pharo-project] which Shout repository should we use?

by Tudor Girba

But, a simple instance variable rename would solve the problem for now. Why is that not good enough now and then remove it later? Cheers, Doru On 16 Aug 2010, at 18:25, Lukas Renggli wrote: > 2010/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Sun, Aug 15, 2010 at 6:21 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> this is a good question. >>> for now I would just update the configuration to point for the >>> repo of >>> lukas :) >> >> But now for example, I need to remove the style instVar in >> PluggableShoutMorph because in Pharo 1.2 it has already such instVar. >> But I don't know if I can commit or if Lukas would integrate such >> change in >> his repo beacuse that will break Shout to load in Pharo 1.1 (the >> image he >> uses) > > I will fix it as soon as the PharoCore 1.2 release candidate is out > and I am able to use the image. > >> so... lukas what do you think we should do? > > So either fix it in Pharo or create your own 'temporary' version of > Shout in the repository where you keep all the versions for building > the images. > > Lukas > > -- > Lukas Renggli > 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 -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Aug. 16, 2010

Re: [Pharo-project] Pharocasts: Display Picasa photos

by laurent laffont

This example is really interesting, I've just learn a lot of things. Laurent On Mon, Aug 16, 2010 at 2:10 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Indeed, nice... > > Here's an adaptation for Flickr... > > | xmlStream xmlDoc photos builder clickBlock | > xmlStream := ' > http://api.flickr.com/services/feeds/photos_public.gne?id=12018791@N06&lang…' > asUrl retrieveContents contentStream. > xmlDoc := XMLDOMParser parseDocumentFrom: xmlStream. > > photos := OrderedCollection new. > xmlDoc tagsNamed: #item do: > [:item| | title thumbUrl photoUrl | > title := (item firstTagNamed: #title) characterData. > thumbUrl := ((item firstTagNamed: #media:thumbnail) > attributeAt: #url) asUrl. > photoUrl := ((item firstTagNamed: #media:content) attributeAt: > #url) asUrl. > photos add: title -> (Form fromBinaryStream: thumbUrl > retrieveContents contentStream) -> photoUrl]. > > clickBlock := [:url :title | | scrollPane | > scrollPane := GeneralScrollPane new > scrollTarget: (builder > newImage: (Form fromBinaryStream: url retrieveContents contentStream)). > scrollPane openInWindow > setLabel: title; > extent: 600@400. > scrollPane color: Color transparent]. > > builder := UITheme builder. > ((builder > newRow: (photos collect: > [:aPhoto| > (builder > newButtonFor: clickBlock > getState: nil > action: #value:value: > arguments: {aPhoto value. aPhoto key key} > getEnabled: nil > label: ((builder newColumn: { > builder newImage: aPhoto key value. > builder newLabel: aPhoto key key}) > cellPositioning: #center; > layoutInset: 10) > help: nil)])) > wrapDirection: #topToBottom; > openInWindow) > setLabel: (xmlDoc firstTagNamed: #title) characterData; > extent: 700@680. > > > Regards, Gary > > ----- Original Message ----- From: "GermÃ¡n Arduino" <garduino(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Cc: "A friendly place where any question about pharo is welcome" < > pharo-users(a)lists.gforge.inria.fr> > Sent: Sunday, August 15, 2010 11:14 PM > Subject: Re: [Pharo-project] Pharocasts: Display Picasa photos > > > > Excellent! >> >> 2010/8/15 laurent laffont <laurent.laffont(a)gmail.com>: >> >>> Learn: >>> - how to get data from an URL >>> - parse XML documents >>> - build a GUI to display photos with Polymorph >>> - how to prototype quickly with debugger and inspector >>> >>> http://pharocasts.blogspot.com/2010/08/see-how-to-get-data-from-url-parse-x… >>> Cheers, >>> Laurent Laffont >>> >>> http://pharocasts.blogspot.com/ >>> http://magaloma.blogspot.com/ >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2010

Re: [Pharo-project] whileTrue: implementation

by merlyn＠stonehenge.com

>>>>> "Hernan" == Hernan Wilkinson <hernan.wilkinson(a)gmail.com> writes: Hernan> whileTrue: aBlock Hernan> self value ifTrue: [ Hernan> aBlock value. Hernan> thisContext restart ] That's an interesting implementation, but the current implementation is clean, and is there only because #perform: has to be able to do it. Maybe this definition could be added as a comment to the method though, to show how you would do it *if* it wasn't inlined. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Aug. 16, 2010

[Pharo-project] whileTrue: implementation

by Hernan Wilkinson

Hi, when I'm teaching OO one of the most interesting subjects is the implementation of control flow structures with closures. Having to implement #ifTrue: only with objects and messages produces in some students the "click" we are looking for, the "ah!" that makes them see the real difference with procedural languages and most no pure object languages (java, c#, etc). When teaching the execution model, I use the #whileTrue: implementation to show them that it is also possible to implement such a thing with just objects and messages. The last semester to my surprise I saw that the #whileTrue: implementation in Pharo is cumbersome, at least for teaching porpoises, because it is based on the "hidden" detail that #whileTrue: is inlined, therefore never sent and its method never executed. The VisualWorks implementation is clearer because it is a recursive implementation that seems to work without knowing that #whileTrue: is inlined (and has a nice comment that explains that implementation detail). Anyway, just for teaching porpoises I thought that providing another implementation would be nice, an implementation based on the execution context, an implementation completely based on objects and messages. For example: whileTrue: aBlock self value ifTrue: [ aBlock value. thisContext restart ] I think it is an interesting example that allows the students to see how we can manipulate the execution environment from inside Smalltalk itself... Anyway, just a comment... not sure if it makes sense to change the implementation just because of this, but maybe putting a comment explaining this option would be nice. Bye, Hernan.

Aug. 16, 2010