- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [COTDC] 38 - PathShape

by laurent laffont

An example: ps := Polygon new addVertex: 0@0; addVertex: 30@30; addVertex: 50@10. self assert: (ps containsPoint: 24@24). self assert: (ps containsPoint: 40@30) not. Transcript show: ps calculatedBounds asString; cr. On Wed, Mar 30, 2011 at 9:22 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > > On Tue, Mar 29, 2011 at 10:47 AM, Gary Chambers <gazzaguru2(a)btinternet.com > > wrote: > >> "I represent a model of an open sequence of connected points that can be >> queried for >> enclosing bounds and whether a point lies along any segment. >> >> I am typically used for drawing with a Canvas." >> >> > Thanks Gary > > > Laurent. > > > >> Regards, Gary >> >> ----- Original Message ----- >> *From:* laurent laffont <laurent.laffont(a)gmail.com> >> *To:* An open mailing list to discuss any topics related to an >> open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> >> *Sent:* Tuesday, March 29, 2011 7:51 AM >> *Subject:* [Pharo-project] [COTDC] 38 - PathShape >> >> Let's comment Polymorph for several days. >> >> Today: PathShape >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> >> >

March 30, 2011

[Pharo-project] [COTDC] 39 - EditableDropListMorph

by laurent laffont

Today: EditableDropListMorph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

March 30, 2011

Re: [Pharo-project] [COTDC] 38 - PathShape

by laurent laffont

On Tue, Mar 29, 2011 at 10:47 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > "I represent a model of an open sequence of connected points that can be > queried for > enclosing bounds and whether a point lies along any segment. > > I am typically used for drawing with a Canvas." > > Thanks Gary Laurent. > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Tuesday, March 29, 2011 7:51 AM > *Subject:* [Pharo-project] [COTDC] 38 - PathShape > > Let's comment Polymorph for several days. > > Today: PathShape > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent > >

March 30, 2011

Re: [Pharo-project] Which methods are really not executed?

by Marcus Denker

On Mar 28, 2011, at 11:28 AM, Mariano Martinez Peck wrote: > Hi folks. I would like to know which are the messages that are not really executed, thus not being intercepted by proxies. > So far, I know: > > 1) > those are inlined by the compiler... > yes. > 2) Special shorcut bytecodes that are in "Smalltalk specialSelectors" / "ParseNode classVarNamed: 'StdSelectors'" / "Smalltalk specialObjectsArray at: 24" > > Here I have a question...if I understand correctly, in this list of selectors there are 3 cases: > > 2.1) methods may or may not be executed depending on the receiver/arguments. For example > 1 + 2 will never send the message #+ to 1. > but 1 + 'mariano' will do. > yes. > 2.2) methods that are NEVER sent, like #class and #== > yes > 2.3) methods that are ALWAYS sent, like #new, #next, #nextPut:, #size, etc. > > So...did I understand correclty this part? > I think so, yes. > > are there more cases where a message may not be really executed? You could see the block creation bytecode as a problematic case. It's not a message, so you can't trap it. But then when we are on that level, the same is with iVar access. Or temp access. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 30, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #4 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 One idea would be to put these selectors in a literalArray in order to consume only one slot. Another idea would be to use a MethodProperties and extend it with ugly stuff (a very bad idea in the long term, but safer in the short term).

March 30, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #3 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 Fully agree. Unfortunately, current implementation seriously limits the number of literals, so care must be taken... numLiterals "Answer the number of literals used by the receiver." ^ (self header bitShift: -9) bitAnd: 16rFF Two literals are consumed by selector or methodProperties see #penultimateLiteral And the target class methodClass "answer the class that I am installed in" ^self numLiterals > 0 ifTrue: [ (self literalAt: self numLiterals) value ] ifFalse: [ nil ] It is possible that some method would compile before the change, and wouldn't after the change... This kind of change would be so easier with a different CompiledMethod format.

March 30, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #2 on issue 2559 by marcus.d...(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 Issue 2911 has been merged into this issue.

March 30, 2011

Re: [Pharo-project] Issue 2911 in pharo: senders of ifNil:ifNotNil: only find literals but not senders

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 2559 Comment #3 on issue 2911 by marcus.d...(a)gmail.com: senders of ifNil:ifNotNil: only find literals but not senders http://code.google.com/p/pharo/issues/detail?id=2911 (No comment was entered for this change.)

March 30, 2011

Re: [Pharo-project] Issue 2911 in pharo: senders of ifNil:ifNotNil: only find literals but not senders

by pharo＠googlecode.com

Comment #2 on issue 2911 by nicolas....(a)gmail.com: senders of ifNil:ifNotNil: only find literals but not senders http://code.google.com/p/pharo/issues/detail?id=2911 Related to issue2559

March 30, 2011

Re: [Pharo-project] Loading GemTools in Pharo 1.1.1-dev

by Norbert Hartl

Am 30.03.2011 um 19:02 schrieb Johan Brichau: > well... it only works with a VM up to version 4.2.2 > well, right! Something I forgot to tell. That is the reason I start it from the command line :) Norbert > everything beyond that ended up in a strange login error, indeed > > On 30 Mar 2011, at 18:19, Dale Henrichs wrote: > >> Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem... >> >> I am glad to hear that some folks are not having trouble ... which only deepens the mystery:) >> >> Dale > >

March 30, 2011