April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol |label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label On Apr 25, 2012, at 1:53 PM, StÃ©phane Ducasse wrote: > I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo: > > self allMorphsDo: [:m | > (m ~= self and: [m respondsTo: #font:]) > ifTrue: [m font: aFont]] > > > Stef

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by Gary Chambers

Well, since a TabLabelMorph could have any morph within it all morphs would have to implement #font: otherwise. It is the price of having both convenience and flexibility. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 12:53 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo: self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]] Stef

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by Gary Chambers

Indeed, unfortunately, due to the way it was done all those years ago, many (Poly)morphs create sub/ancillary morphs in the initialize. If the theme is not set they will get created with the current theme, rather than the theme doing the initial creation. I suppose the submorph creation could be done in a separate method and called after initalize and theme setting, a lot more work to do that way though. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 12:55 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote: > Hi Stef, > > I guess you mean to move the resizing bits. I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef > It is explicit in ExpanderMorph because that's how the title > should be in the context of an expander. > > The ExpanderTitleMorph *could* be used elsewhere with different > properties. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" > <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, April 25, 2012 10:42 AM > Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes > > > Gary > > I was wondering if a part of this method could be used in > ExpanderTitleMorph>>initialize ? > > ExpanderMorph>>defaultTitleMorph > "Answer a default title morph for the receiver." > > ^ExpanderTitleMorph basicNew > basicTheme: self theme; > initialize; > hResizing: #spaceFill; > vResizing: #shrinkWrap; > basicTheme: nil > > > > > On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: > >> Finally found the time to package out. >> Have tested a bit after fixing some conflicts. >> A few minor ones left for DropListMorph as it seems the wrapSelector >> stuff has changed (and appears broken in 2.0 too). >> >> Attached cs and description of changes >> >> Regards, Gary >> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> > > >

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by Gary Chambers

Yep, that's what I expected as fix ;-) Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project(a)lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 11:58 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben ------------------------------------------------------------------------------ On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote: Hi, well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index: Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list... E.g. (UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow Easy to fix but I'll wait till it is before I post some of my changes that were in conflict. Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project(a)lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Do you have an example where the DropListMorph wrapSelector is broken ? Ben On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> ------------------------------------------------------------------------------ Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote: > Hi, > > well it seems that there is now an inst var on DropListMorph for wrapSelector, > only used by getter/setter and wrapItem:index: > > Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. > So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as > updateList never gets sent to the list... > > E.g. > > (UITheme builder > newDropListFor: (ListModel new list: {Object. Rectangle}) > list: #list > getSelected: nil > setSelected: nil > getEnabled: nil > help: nil) > wrapSelector: #className; > openInWindow > > > Easy to fix but I'll wait till it is before I post some of my changes that were in conflict. > > Regards, Gary > ----- Original Message ----- > From: Benjamin > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, April 25, 2012 10:28 AM > Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes > > Do you have an example where the DropListMorph wrapSelector is broken ? > > Ben > > On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: > >> Finally found the time to package out. >> Have tested a bit after fixing some conflicts. >> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). >> >> Attached cs and description of changes >> >> Regards, Gary >> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> > >

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote: > Hi Stef, > > I guess you mean to move the resizing bits. I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef > It is explicit in ExpanderMorph because that's how the title > should be in the context of an expander. > > The ExpanderTitleMorph *could* be used elsewhere with different > properties. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, April 25, 2012 10:42 AM > Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes > > > Gary > > I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ? > > ExpanderMorph>>defaultTitleMorph > "Answer a default title morph for the receiver." > > ^ExpanderTitleMorph basicNew > basicTheme: self theme; > initialize; > hResizing: #spaceFill; > vResizing: #shrinkWrap; > basicTheme: nil > > > > > On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: > >> Finally found the time to package out. >> Have tested a bit after fixing some conflicts. >> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). >> >> Attached cs and description of changes >> >> Regards, Gary >> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> > > >

April 25, 2012

Re: [Pharo-project] Error at startup with the NonInteractiveUIManager

by Sean P. DeNigris

fstephany wrote > >> ==== Startup Error: PrimitiveFailed: primitive #primGetPosition: in >> MultiByteFileStream failed > I wonder if it's related to the problem I've been having with OSProcess (http://forum.world.st/OSProcess-is-process-done-tp4569088p4575379.html) I'm using a recent Mac Cocoa Cog VM from Jenkins... Sean -- View this message in context: http://forum.world.st/Error-at-startup-with-the-NonInteractiveUIManager-tp4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote: > Hi Stef, > > I guess you mean to move the resizing bits. I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef > It is explicit in ExpanderMorph because that's how the title > should be in the context of an expander. > > The ExpanderTitleMorph *could* be used elsewhere with different > properties. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, April 25, 2012 10:42 AM > Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes > > > Gary > > I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ? > > ExpanderMorph>>defaultTitleMorph > "Answer a default title morph for the receiver." > > ^ExpanderTitleMorph basicNew > basicTheme: self theme; > initialize; > hResizing: #spaceFill; > vResizing: #shrinkWrap; > basicTheme: nil > > > > > On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: > >> Finally found the time to package out. >> Have tested a bit after fixing some conflicts. >> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). >> >> Attached cs and description of changes >> >> Regards, Gary >> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> > > >

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo: self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]] Stef

April 25, 2012

Re: [Pharo-project] CogVM on linux machines

by Esteban Lorenzano

Hi Herve, On some really old hardware, even with latest ubuntu, I had problems running applications with Cog. In that cases I found than Stack versions or even old interpreter versions are much more stable. Don't ask me why, just that it happens. Maybe you can try with some of those vms? best, Esteban On Apr 25, 2012, at 11:51 AM, Herve Verjus wrote: > Hello All, > > I am currently try to deploy the 1.4 Pharo CogVm on different linux machines. The underlying aim is to propose a stable linux configuration that will be deployed in our university (for Smalltalk/Pharo lectures and students practice). As far as for now, we have windows workstations on which Pharo (1.3) was installed: during this year, we meet some troubles (Pharo images containing students' work no more readable or crashing all the time :-( ). Students complain... > > I really want to seperate VM install (on the workstations) with the image files (on separate students' home directories) that's why the oneClick bundle does not interest me. > > I made some tests on different linux machines and I find some problems: > > - on a 5 years old machine with a fresh installed latest Ubuntu (v11), the CogVm crashes (segmentation fault)...while the 1.4 oneClick installation is running well. The same install on another but same model machine with the same linux distribution (same version), the CogVm immediately ends with this error > Syntax error: "(" unexpected > - on a more recent machine with a up-to-date Ubuntu LTS (v10), the CogVm works well > > Any advices are welcome and if some of you have linux requirements/specifications don't hesitate to tell me ;-) > > Regards, > > Herve > -- > -- Herve VERJUS -----ooOoo----- http://univ.herveverjus.com/ > -- Universite de Savoie - IAE Savoie Mont-Blanc > -- Directeur du Departement Technologie et Management / IMUS-IAE > -- Resp. Master Management et Technologies de l'Information > -- B.P. 80439 / F-74944 ANNECY-LE-VIEUX > -- Reception: +33 (0)450092443 - Office 009: +33 (0)450092415 > -- LISTIC Lab. - Polytech Annecy-Chambery Office A225 >

April 25, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by Benjamin

Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote: > Hi, > > well it seems that there is now an inst var on DropListMorph for wrapSelector, > only used by getter/setter and wrapItem:index: > > Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. > So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as > updateList never gets sent to the list... > > E.g. > > (UITheme builder > newDropListFor: (ListModel new list: {Object. Rectangle}) > list: #list > getSelected: nil > setSelected: nil > getEnabled: nil > help: nil) > wrapSelector: #className; > openInWindow > > > Easy to fix but I'll wait till it is before I post some of my changes that were in conflict. > > Regards, Gary > ----- Original Message ----- > From: Benjamin > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, April 25, 2012 10:28 AM > Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes > > Do you have an example where the DropListMorph wrapSelector is broken ? > > Ben > > On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: > >> Finally found the time to package out. >> Have tested a bit after fixing some conflicts. >> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). >> >> Attached cs and description of changes >> >> Regards, Gary >> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> > >

April 25, 2012