- Pharo-dev - lists.pharo.org

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

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

by Benjamin

I do not get why, but in your example, wrapSelector instance is always nil ... I use this (DropListMorph + wrapSelector) for nautilus, and it works as expected (the list is wrapped too). 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 Gary Chambers

Hi Stef, I guess you mean to move the resizing bits. 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

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] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by StÃ©phane Ducasse

I added: \subsection{How to Deal with Package Structure Changes?} Imagine that you want to develop an application on both Pharo13 and Pharo14, and that your application has only a package for one version: either because you changed your application or because the package was integrated into the base system. The solution is to define the dependencies and use the symbolic tag as a marker, as follows: \begin{code}{} spec for: #'pharo' do: [ spec package: 'that depends upon zinc' with: [ "the common required packages for your package" ]. spec for: #'pharo1.3.x' do: [ spec project: 'Zinc' with: [ spec className: 'ConfigurationOfZinc'; versionString: #'stable'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec package: 'that depends upon zinc' with: [ spec requires: #('Zinc') ]. ]. \end{code} If you use the \ct{stable} version in your baseline there is no need to anything special in your version specification. stef > Stef > > > >> Haha, no problem at all ... glad to help:) >> >> Dale >> >> ----- Original Message ----- >> | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> >> | To: pharo-project(a)lists.gforge.inria.fr >> | Sent: Tuesday, April 24, 2012 4:53:21 PM >> | Subject: Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 >> | >> | Haha you made my day Dale! >> | I didn't know that you coul specify #'pharo1.3.x' in the baseline. >> | That's exactly what I was looking for. >> | >> | Sorry for the noise! >> | >> | On 24/04/12 16:49, Dale Henrichs wrote: >> | > spec for: #'pharo1.3.x' do: [ >> | > spec project: 'Zinc' with: [ >> | > spec >> | > className: 'ConfigurationOfZinc'; >> | > versionString: #'stable'; >> | > repository: 'http://www.squeaksource.com/Metacel >> | >> | >> > >

April 25, 2012