October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Hierarchy browsers & implementers of

by Petr VÃ¡cha

I know Smalltalk hierarchy, I just wanted to point out, that Hierarchy Browser does not provide (maybe I am dumb, but I do not see any) obvious way to show the hierarchy to see that Array class inherits from Behavior. PV. ----- PÅ®VODNÃ ZPRÃVA ----- Od: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> Komu: "Petr VÃ¡cha" <recycler(a)volny.cz> PÅedmÄt: Re: Hierarchy browsers & implementers of Datum: 7.10.2009 - 21:22:42 > I suggest you to read the chapter on the Smalltalk > model in the Squeak > or pharo by example book > the key is: > > when you look for a message you look in the CLASS of > the receiver > then its superclasses. > > So when you look for new sent to Array you should look > in the Array > class superclasses and you will see it contains > Behavior before ProtoObject > > Stef > > PS: you can sent to the mailing-list just register > to it. You do not > need to have a google account. > > On Oct 7, 2009, at 1:00 PM, Petr VÃ¡cha wrote: > > > Hi again, > > when try to find out that Array>>new: bug I found > > one thing that I > > > think > > may be very confusing - somehow mangled information > > from hierarchy > > > browsers > > (see figure). > > > > Array>>new: calls primitive and uses self>>basicNew: > > call as fallback. > > > Array does not implement basicNew: so I tried to > > find implementors of > > > it. Behavior has this implementation. However, when > > you show hierarchy > > > of Array, it ends in ProtoObject with no Behavior > > involved. I think > > > this to be is somewhat confusing for beginners especially > > when they > > > are trying to get into method lookup chain. > > > > Petr Vacha > > > > > > <pharo-browsers.jpg> >

Oct. 7, 2009

[Pharo-project] Loading Gemstone Variable (Indexable) classes into Pharo via Monticello

by rkrock＠locksleycreeksoftware.com

I have the following in Gemstone: FristClass which is a indexableSublass of Object. SecondClass which is a subclass of FirstClass. When I save this to Monticello and then load it into Pharo, the load fails on the 'recompile' because the SecondClass is not of type #variable. The load works when I modify the method MCClassDefinition>>createClass to use the superclass' type when the superclass type is #variable. --- current way ---- ... type: type; ... --- hacked way ---- .... type: ((superClass typeOfClass isSymbol not and: [superClass typeOfClass isVariable]) ifTrue: [superClass typeOfClass] ifFalse: [type]); .... With this I was sucessfully able to important the code into Pharo. I am able to go from Pharo to GemStone with no problems. Is there a general solution to this problem? It obviously will not occur very often. Regards, Reg

Oct. 7, 2009

Re: [Pharo-project] calling for a fixer :)

by StÃ©phane Ducasse

Thanks johan!!! did you open a ticket? Stef On Oct 7, 2009, at 3:23 PM, Johan Brichau wrote: > > On 07 Oct 2009, at 15:19, Igor Stasenko wrote: >> >> Maybe its worth to change #literalsDo: method to not iterate over >> class and method selector? >> And then use it in #refersToLiteral: ? > > Actually, I just noticed after publishing the fix that the last-but- > one position can contain either the method selector -or- the method's > pragma (which in turn will hold the method's selector). > > So, since the #refersToLiteral: method is supposed to return also > references to literals from the pragma's (see somment) I had to adapt > the fix to take the last-but-one position as a special case... rather > than simply excluding it. > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2009

Re: [Pharo-project] [update] #10469

by StÃ©phane Ducasse

Henry I meant 1233 http://code.google.com/p/pharo/issues/detail?can=2&q=1233&colspec=ID%20Type… Stef On Oct 7, 2009, at 9:35 PM, StÃ©phane Ducasse wrote: > Yes I asked damien if it could produce a slice with all the code > because I could not easily see the conflict. > What I merged what another related issue 925 or 955 from memory. and > we have to integrate the pendings > items from 1235 (which should still be open). > > Stef > > > On Oct 7, 2009, at 2:27 PM, Henrik Johansen wrote: > >> The messages listed in the issue >> (Browser >> addSystemCategory, >> PluggableThemedPanelMorph >> duplicateClassWithNewName: aSymbol) >> have not been modified to handle the nil case on cancel. >> >> I'm not sure what in this update addresses them. >> >> They do showcase yet a few more cases where you do NOT want to handle >> nil and empty differently though. :) >> >> Cheers, >> Henry >> >> On Oct 7, 2009, at 12:18 49PM, StÃ©phane Ducasse wrote: >> >>> >>> 10469 >>> ----- >>> - Issue 1235: UIManager #request:initialAnswer: returns nil on >>> Cancel >>> instead of empty string >>> >>> _______________________________________________ >>> 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

Oct. 7, 2009

Re: [Pharo-project] calling for a fixer :)

by StÃ©phane Ducasse

I want benchs :) Stef On Oct 7, 2009, at 9:24 PM, Igor Stasenko wrote: > 2009/10/7 Lukas Renggli <renggli(a)gmail.com>: >>> Okay, if you need to visit pragmas as well, then why don't do it: >> >> Yes, this is important. Otherwise you can't browser for references to >> a Pragma anymore. >> >>> CompiledMethod>>refersToLiteral: aLiteral >>> >>> self literalsDo: [ blablah ]. >>> self pragmas do: [ blah blah ] >>> >>> ^ false >>> >>> which makes this method immune from any future changes in >>> CompiledMethod format. >>> So, we don't need to think about 'fixing' it again and again, each >>> time we need to hack things. >> >> This would introduce a major performance bottleneck for commonly used >> Smalltalk features like senders/implementors/references. >> > > Well, before stating that, we should measure it. > My point, that we should keep a minimum methods, which is aware of a > deep internals of method's format. > Then it would be easier to maintain it. > >> Lukas >> >> -- >> Lukas Renggli >> http://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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2009

Re: [Pharo-project] [update] #10469

by StÃ©phane Ducasse

Yes I asked damien if it could produce a slice with all the code because I could not easily see the conflict. What I merged what another related issue 925 or 955 from memory. and we have to integrate the pendings items from 1235 (which should still be open). Stef On Oct 7, 2009, at 2:27 PM, Henrik Johansen wrote: > The messages listed in the issue > (Browser >> addSystemCategory, > PluggableThemedPanelMorph >> duplicateClassWithNewName: aSymbol) > have not been modified to handle the nil case on cancel. > > I'm not sure what in this update addresses them. > > They do showcase yet a few more cases where you do NOT want to handle > nil and empty differently though. :) > > Cheers, > Henry > > On Oct 7, 2009, at 12:18 49PM, StÃ©phane Ducasse wrote: > >> >> 10469 >> ----- >> - Issue 1235: UIManager #request:initialAnswer: returns nil on Cancel >> instead of empty string >> >> _______________________________________________ >> 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

Oct. 7, 2009

Re: [Pharo-project] calling for a fixer :)

by Igor Stasenko

2009/10/7 Lukas Renggli <renggli(a)gmail.com>: >> Okay, if you need to visit pragmas as well, then why don't do it: > > Yes, this is important. Otherwise you can't browser for references to > a Pragma anymore. > >> CompiledMethod>>refersToLiteral: aLiteral >> >> Â self literalsDo: [ blablah ]. >> Â self pragmas do: [ blah blah ] >> >> Â Â Â ^ false >> >> which makes this method immune from any future changes in CompiledMethod format. >> So, we don't need to think about 'fixing' it again and again, each >> time we need to hack things. > > This would introduce a major performance bottleneck for commonly used > Smalltalk features like senders/implementors/references. > Well, before stating that, we should measure it. My point, that we should keep a minimum methods, which is aware of a deep internals of method's format. Then it would be easier to maintain it. > Lukas > > -- > Lukas Renggli > http://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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 7, 2009

Re: [Pharo-project] Hierarchy browsers & implementers of

by StÃ©phane Ducasse

I suggest you to read the chapter on the Smalltalk model in the Squeak or pharo by example book the key is: when you look for a message you look in the CLASS of the receiver then its superclasses. So when you look for new sent to Array you should look in the Array class superclasses and you will see it contains Behavior before ProtoObject Stef PS: you can sent to the mailing-list just register to it. You do not need to have a google account. On Oct 7, 2009, at 1:00 PM, Petr VÃ¡cha wrote: > Hi again, > when try to find out that Array>>new: bug I found one thing that I > think > may be very confusing - somehow mangled information from hierarchy > browsers > (see figure). > > Array>>new: calls primitive and uses self>>basicNew: call as fallback. > Array does not implement basicNew: so I tried to find implementors of > it. Behavior has this implementation. However, when you show hierarchy > of Array, it ends in ProtoObject with no Behavior involved. I think > this to be is somewhat confusing for beginners especially when they > are trying to get into method lookup chain. > > Petr Vacha > > > <pharo-browsers.jpg>

Oct. 7, 2009

[Pharo-project] Fwd: problem with updating checkBoxes in morph

by StÃ©phane Ducasse

Begin forwarded message: > From: "Gary Chambers" <gary(a)pinesoft.co.uk> > Date: October 7, 2009 12:40:16 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: RE: [Pharo-project] problem with updating checkBoxes in morph > > The button inherits from three-phase button and, for "compatability" > also does not call the Morph method for mouseDown (except when > disabled). That is why the event is never triggered. > > Most morphs of the pluggable variety expect to work with proper > model objects, not always easy with a (potentially dynamic) > collection. > Perhaps an intermediate model would be appropriate for each checkbox > that holds the selection state and end-model (some kind of "context" > it seems from his original post). On state change an event could be > triggered (preferred over change/update). > > Perhaps he should be using radio buttons, given the implication of > "one-of-many" (is the same class, just different appearance). > > -----Original Message----- > From: StÃ©phane Ducasse [mailto:stephane.ducasse@inria.fr] > Sent: 07 October 2009 11:23 AM > To: Gary Chambers > Subject: Fwd: [Pharo-project] problem with updating checkBoxes in > morph > > did you notice this strange behavior with checkboxes? >> In this example, when you click on the check box, all the other >> checkboxes should be updated and selected. >> This works when you click on the checkbox label BUT NOT on the >> checkbox button. > > > stef > Begin forwarded message: > >> From: Cyrille Delaunay <cy.delaunay(a)gmail.com> >> Date: October 7, 2009 10:10:07 AM GMT+02:00 >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] problem with updating checkBoxes in >> morph >> Reply-To: Pharo-project(a)lists.gforge.inria.fr >> >> => this is a small exemple of my problem that you can run in your >> own image (also available in the class side of UITheme by merging >> the 'Polymorph-Widgets' package in the PharoInBox repository) : >> >> exampleProblemUpdatingCheckboxes >> "little example to show the problem with the method >> #on:send:to:with for a CheckboxMorph : >> In this example, when you click on the check box, all the other >> checkboxes should be updated and selected. >> This works when you click on the checkbox label BUT NOT on the >> checkbox button. >> " >> "self exampleProblemUpdatingCheckboxes" >> | builder dialog checkboxes | >> checkboxes := OrderedCollection new. >> builder := ExampleBuilderMorph new. >> dialog := (builder newPluggableDialogWindow: 'Example :') >> useDefaultOKButton . >> >> dialog contentMorph: ( >> dialog newGroupboxForAll: { >> checkboxes add: >> (dialog newCheckboxFor: >> (ValueHolder new contents: false) >> getSelected: #contents >> setSelected: #contents: >> label: '1' >> help: ''). >> checkboxes add: >> (dialog newCheckboxFor: >> (ValueHolder new contents: false) >> getSelected: #contents >> setSelected: #contents: >> label: '2' >> help: ''). >> checkboxes add: >> (dialog newCheckboxFor: >> (ValueHolder new contents: false) >> getSelected: #contents >> setSelected: #contents: >> label: '3' >> help: ''). >> } >> ); model: nil. >> checkboxes do: [:each | each on: #click send: >> #updateCheckboxes:a:b: to: self withValue: checkboxes ]. >> builder openModal: dialog. >> >> => and the method : >> >> updateCheckboxes: collectionOfCheckboxes a:a b:b >> >> collectionOfCheckboxes do: [:each | each buttonMorph selected: >> true]. >> >> >> 2009/10/6 Igor Stasenko <siguctua(a)gmail.com> >> I'm a bit wonder, why you sending a #buttonMorph to checkbox morph, >> trying to intercept >> a messages? >> As to me this is a wrong approach, because you as a user of checkbox, >> should not care >> about its internals, and speak directly with checkbox public layer , >> but not with its internal components. >> >> 2009/10/6 Cyrille Delaunay <cy.delaunay(a)gmail.com>: >> > here is the code of the method creating the checkboxes: >> > checkBoxes := OrderedCollection new. >> > builder := ExampleBuilderMorph new. >> > dialog := (builder newPluggableDialogWindow: 'Context to import :') >> > useDefaultOKButton . >> > dialog contentMorph: ( >> > dialog newRow: { >> > dialog newGroupboxForAll: >> > (self allContexts collect: [:each | (checkBoxes add: (dialog >> > newCheckboxFor: >> > (ValueHolder new >> > contents: (collectionWithItemsToCheck includes: each)) >> > getSelected: #contents >> > setSelected: #contents: >> > label: each asString >> > help: '') >> > ). >> > ]) >> > } >> > ); >> > model: nil. >> > checkBoxes do: [:each | each on: #click send: >> #updateDependenciesFor:i:a: >> > to: self withValue: each label asString]. >> > => That code make what I want when I click on the label, but with: >> > checkBoxes do: [:each | each buttonMorph on: #click send: >> > #updateDependenciesFor:i:a: to: self withValue: each label >> asString]. >> > => nothing happen when I click on the checkbox button. >> > >> > 2009/10/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> >> >> can you send some text :) >> >> >> >> On Oct 6, 2009, at 2:02 PM, Cyrille Delaunay wrote: >> >> >> >> > I join a screenshot of my code. >> >> > >> >> > 2009/10/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> > cyrille >> >> > >> >> > do you have a piece of code to illustrate your problem? >> >> > Let me rephrase our discussions: >> >> > >> >> > you can get the associated checkbox event (set by >> >> > on: #click send: #amessage to: receiver) raised only >> >> > when you click on the label but not on the tick. >> >> > >> >> > And that >> >> > checkbox buttonMorph on: #click send: #amessage to: >> receiver, >> >> > is not working on click >> >> > but checkbox buttonMorph on: #mouseDown send: #amessage to: >> >> > receiver, >> >> > is. >> >> > >> >> > >> >> > Stef >> >> > >> >> > >> >> > >> >> > On Oct 6, 2009, at 12:08 PM, Cyrille Delaunay wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > Here is what I want to do: >> >> > > >> >> > > - I have checkbox: ChekboxMorph new >> >> > > - A checkbox is made of a label and a button >> >> > > - I want to do a specific action when there is a mouse click >> on the >> >> > > button >> >> > > >> >> > > For that: >> >> > > >> >> > > - I saw that there is a method #on:send:to: in Morph with >> wich we >> >> > > can do: >> >> > > >> >> > > checkbox on: #click send: #amessage to: receiver >> >> > > >> >> > > Problem: >> >> > > >> >> > > - when I do >> >> > > checkbox on: #click send: #amessage to: receiver, >> >> > > all is ok. >> >> > > - when I do >> >> > > checkbox buttonMorph on: #click send: #amessage to: >> >> > receiver, >> >> > > to consider the click on the button, it doesn't work, the >> event is >> >> > > never handled (whereas #mouseDown for example is handled). >> >> > > >> >> > > >> >> > > _______________________________________________ >> >> > > 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 >> >> > >> >> > <checkboxes.tiff>_______________________________________________ >> >> > 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 >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > > > > Click here to report this email as spam. > > > > > Ã¼ Consider your responsibility to the environment - think before you > print! > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > > ******************************************************************************************************************************************* > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA >

Oct. 7, 2009

[Pharo-project] Linux so

by Schwab,Wilhelm K

Hello all, Some dumb questions related to my ongoing migration away from Windows. Something that I have found useful is to write numerical analysis code (internally using templates, streams, etc.) in C++, and then compile them as extern "C" something like extern "C" _export void DoSomething(float * data, int rows, int columns) { // C++ specifics are legal herein; arguments // and return type must be legal for C - e.g. no references // and no classes; structs are ok. } On Windows with MinGW, the exporting of the function above seems to be almost magically easy. Do similar tricks work on Linux? On Linux, I intend to use gcc and Code::Blocks, unless somebody has a better idea. I bring this up in part because some things (tight loops) are best left to statically typed languages, C++ has a slight edge over Smalltalk on syntax for translating equations, I already have a lot of working C++ code, and I might be able to ease into getting GSL talking to Pharo before having to tackle the entire interface. I am hoping to add something to an evolving library, recompile, and perhaps after restarting Pharo have access to the new function(s) with fairly little hassle. Is that reasonable to ask? Any advice or warnings? Bill

Oct. 7, 2009