- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.3 Seaside 'client' build ?

by Sven Van Caekenberghe

Hi (Marcus), I was looking for a Pharo 1.3 Seaside 'client' build on the CI server(s) but couldn't find it. It used to be available for 1.2.x (this seems to be gone as well). I think that for good reciprocal relations with Seaside, it would be very good to have a tested build of the current main Pharo images. It make a good testcase as well. And it saves quite some work, loading the Seaside config is pretty slow. I remember reading something about some clients being removed from the CI's, but I didn't register it fully. Thx, Sven PS: Another questions is: is 1.3 'released', if so where are the links on the website, where is the 'noise' ?

July 25, 2011

Re: [Pharo-project] [update 1.4] #14057

by Gary Chambers

Some trickyness. Use of a combined accessor vs. separate get/set selectors may cause some problems since less flexible. Users exist in Slider subclasses and DiffMorph. Plus the TEasilyThemed and UITheme helpers. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "pharo-project open-source Smalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, July 22, 2011 6:31 PM Subject: [Pharo-project] [update 1.4] #14057 14057 ----- - Issue 4513: ScrollBar and MorphicModel needs cleaning. Stef and Igor killing tha big monster - Part two. :) http://code.google.com/p/pharo/issues/detail?id=4513 Gary it would be good that you check because we have two ways to to a perform: accessor and setValueSelector while only one would be enough. Stef and Igor

July 25, 2011

Re: [Pharo-project] Polymorph validation

by Gary Chambers

You could set the regex for the field E.g. <the field morph> converter regexString: '.+' That would hilight any invalid fields. Still need to check on "OK", or make that button's enablement depend on whether the model is valid. Regards, Gary ----- Original Message ----- From: "Jeff Gray" <jeff(a)rogerthedog.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, July 25, 2011 2:09 PM Subject: [Pharo-project] Polymorph validation > Just playing with Laurent's example contact manager. > So next logical step - how to validate the fields? > E.g. both first name and surname must have a value. > Is there a method to override? Something I need to implement in the model > class? > Got any hints? :-) > > -- > View this message in context: > http://forum.world.st/Polymorph-validation-tp3692714p3692714.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 25, 2011

[Pharo-project] Polymorph validation

by Jeff Gray

Just playing with Laurent's example contact manager. So next logical step - how to validate the fields? E.g. both first name and surname must have a value. Is there a method to override? Something I need to implement in the model class? Got any hints? :-) -- View this message in context: http://forum.world.st/Polymorph-validation-tp3692714p3692714.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 25, 2011

Re: [Pharo-project] Fwd: Re: Profile interpretation

by Philippe Marschall

On 07/25/2011 12:44 PM, Hilaire Fernandes wrote: > Read bellow and tell me what you think about it? > The way MessageTally renders the method tree seems to me inconsistent. > > Hilaire > > -------- Message original -------- > Sujet: Re: Profile interpretation > Date : Sun, 24 Jul 2011 20:26:33 +0200 > De : Andreas Raab <andreas.raab(a)gmx.de> > RÃ©pondre Ã : The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > Pour : The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > Groupes de discussion: gmane.comp.lang.smalltalk.squeak.general > RÃ©fÃ©rences : <j0gk38$b7i$2(a)dough.gmane.org> <4E2C0131.4040709(a)gmx.de> > <j0hi13$70h$1(a)dough.gmane.org> > > On 7/24/2011 18:42, Hilaire Fernandes wrote: >> As we are writing about bogus, you can explain me one aspect of the >> profile I found hard to interpret. If you look at this profile snippet >> (I hope it will print in a readable form): >> >>> | | 16.7% {2692ms} DrGeo>>updateDirtyCostumes >>> | | 16.6% {2686ms} DrGAngle3PointsCostume(DrGMathItemCostume)>>update >>> | | 10.4% {1674ms} DrGAngle3PointsCostume>>redraw >>> | | |9.4% {1513ms} DrGAngle3PointsCostume>>redrawShape >>> | | | 9.3% {1496ms} DrGAngle3PointsCostume>>redrawArc >>> | | | 9.2% {1485ms} DrGArcMorph>>center:radius:origin:length: >>> | | | 8.6% {1395ms} DrGArcMorph(PolygonMorph)>>computeBounds >>> | | | 7.8% {1255ms} DrGArcMorph(PolygonMorph)>>curveBounds >>> | | | 7.6% {1231ms} DrGArcMorph(PolygonMorph)>>lineSegmentsDo: >>> | | | 7.2% {1162ms} DrGArcMorph(PolygonMorph)>>coefficients >>> | | | 4.3% {687ms} Cubic>>bestSegments >>> | | | 2.8% {447ms} Cubic>>calcEnoughSegments >>> | | | |1.8% {297ms} Cubic>>enough:withMeasure:withIn: >>> | | | | 1.8% {291ms} Cubic>>measureFor: >>> | | | | 1.6% {251ms} Cubic(SequenceableCollection)>>polynomialEval: >>> | | | 1.5% {239ms} Cubic>>honeIn: >>> | | 3.1% {501ms} DrGSegmentCostume>>redraw >> >> >> The way the message calls are nested in the profile result, for me it >> says: DrGSegmentCostume>>redraw is called in the context of >> DrGAngle3PointsCostume(DrGMathItemCostume)>>update which is absolutely >> not the case. So what is it? > > Don't know. I have not seen any problems with incorrectly reported call > trees. The only thing I could imagine is that the calls to > DrGMathItemCostume are incorrectly coalesced by MessageTally. > Alternatively, it's possible that changes to context or compiled method > in Pharo have something to do with it (MessageTally relies a lot on > method / context comparisons for reporting). > >> Le 24/07/2011 13:25, Andreas Raab a Ã©crit : >>> Your best bet at this point is probably to go back to a VM that doesn't >>> have the problem (probably as far as 3.6 if that's feasible) or to >>> extract the OpenQwaq system profiler which you could then run on the >>> desktop (I'm not sure if it's supported by the Stack VM; you could try >>> it to see if it works on the iPad as well). >> >> Is this OpenQwaq system profiler located at the image level or VM level? > > It's purely in the image but it needs VM support which I think is only > in Cog. I extracted it and uploaded it to SqueakSource [1]. It's still GPLv2 [1] http://www.squeaksource.com/SystemProfilerPharo.html Cheers Philippe

July 25, 2011

[Pharo-project] Fwd: Re: Profile interpretation

by Hilaire Fernandes

Read bellow and tell me what you think about it? The way MessageTally renders the method tree seems to me inconsistent. Hilaire -------- Message original -------- Sujet: Re: Profile interpretation Date : Sun, 24 Jul 2011 20:26:33 +0200 De : Andreas Raab <andreas.raab(a)gmx.de> RÃ©pondre Ã : The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Pour : The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Groupes de discussion: gmane.comp.lang.smalltalk.squeak.general RÃ©fÃ©rences : <j0gk38$b7i$2(a)dough.gmane.org> <4E2C0131.4040709(a)gmx.de> <j0hi13$70h$1(a)dough.gmane.org> On 7/24/2011 18:42, Hilaire Fernandes wrote: > As we are writing about bogus, you can explain me one aspect of the > profile I found hard to interpret. If you look at this profile snippet > (I hope it will print in a readable form): > >> | | 16.7% {2692ms} DrGeo>>updateDirtyCostumes >> | | 16.6% {2686ms} DrGAngle3PointsCostume(DrGMathItemCostume)>>update >> | | 10.4% {1674ms} DrGAngle3PointsCostume>>redraw >> | | |9.4% {1513ms} DrGAngle3PointsCostume>>redrawShape >> | | | 9.3% {1496ms} DrGAngle3PointsCostume>>redrawArc >> | | | 9.2% {1485ms} DrGArcMorph>>center:radius:origin:length: >> | | | 8.6% {1395ms} DrGArcMorph(PolygonMorph)>>computeBounds >> | | | 7.8% {1255ms} DrGArcMorph(PolygonMorph)>>curveBounds >> | | | 7.6% {1231ms} DrGArcMorph(PolygonMorph)>>lineSegmentsDo: >> | | | 7.2% {1162ms} DrGArcMorph(PolygonMorph)>>coefficients >> | | | 4.3% {687ms} Cubic>>bestSegments >> | | | 2.8% {447ms} Cubic>>calcEnoughSegments >> | | | |1.8% {297ms} Cubic>>enough:withMeasure:withIn: >> | | | | 1.8% {291ms} Cubic>>measureFor: >> | | | | 1.6% {251ms} Cubic(SequenceableCollection)>>polynomialEval: >> | | | 1.5% {239ms} Cubic>>honeIn: >> | | 3.1% {501ms} DrGSegmentCostume>>redraw > > > The way the message calls are nested in the profile result, for me it > says: DrGSegmentCostume>>redraw is called in the context of > DrGAngle3PointsCostume(DrGMathItemCostume)>>update which is absolutely > not the case. So what is it? Don't know. I have not seen any problems with incorrectly reported call trees. The only thing I could imagine is that the calls to DrGMathItemCostume are incorrectly coalesced by MessageTally. Alternatively, it's possible that changes to context or compiled method in Pharo have something to do with it (MessageTally relies a lot on method / context comparisons for reporting). > Le 24/07/2011 13:25, Andreas Raab a Ã©crit : >> Your best bet at this point is probably to go back to a VM that doesn't >> have the problem (probably as far as 3.6 if that's feasible) or to >> extract the OpenQwaq system profiler which you could then run on the >> desktop (I'm not sure if it's supported by the Stack VM; you could try >> it to see if it works on the iPad as well). > > Is this OpenQwaq system profiler located at the image level or VM level? It's purely in the image but it needs VM support which I think is only in Cog. Cheers, - Andreas

July 25, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Marcus Denker

On Jul 24, 2011, at 10:29 AM, StÃ©phane Ducasse wrote: > Doru can you add the page on morphic on this list? > Marcus can you add a page to OPAL? > with pending todo? Ok, I will dot that. -- Marcus Denker Do it together: http://taskfor.us

July 25, 2011

Re: [Pharo-project] About the site

by Marcus Denker

On Jul 22, 2011, at 10:10 PM, Nicolas Cellier wrote: > Pharo 1.4 is not easily accessible from the site > http://www.pharo-project.org/home > Also true for the new Jenkins continuous integration server > https://ci.lille.inria.fr/pharo/ > > Pharo 1.3 is listed as unstable, and not in released. Hasn't it been > released yet ? No, not yetâ¦ we should do the last touches and release it. I think we will do it this week. > Generally, where should problems with the site be reported ? In the normal tracker: http://code.google.com/p/pharo/issues/list I really think we need a bug tracker that has sub-project support (tags alone don't do it). Imagine we would have real trackers for all the sub-partsâ¦ (and even things like "cleaning") it would look far more manageable. Marcus -- Marcus Denker Do it together: http://taskfor.us

July 25, 2011

Re: [Pharo-project] A request or suggestion.

by Friedrich Dominicus

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > Check the settings because you can say to the window manager that it should stagger or position them in another way. > Else have a look at TWM > Stef I tried to change the window positioning but that was not what I wanted to have I want in the low applicaton bar a group of Workspaces a group of Browsers etc. So what option are you referring to? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

July 25, 2011

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] help needed with the new FFI plugin...

by David T. Lewis

On Sat, Jul 23, 2011 at 01:50:49PM +0200, Levente Uzonyi wrote: > > Threaded FFI is great, it opens new possibilities, but nowadays the > feature I miss the most is the ability to call functions in 64-bit > (x86_64) libraries (from a 32-bit VM/image). As far as I know, mixing 32-bit and 64-bit libraries in a single executable (VM) is not feasible, at least not on Linux. Maybe it would work in the case of statically linked libraries, I'm not certain. The traditional FFI does not work for 64-bit VMs, and I expect that this needs to be resolved for any new FFI implementation as well, because some of the issues were in the interpreter itself, not just the FFI plugin. The issue also may affect other things, e.g. Igor's proposed #primLoadModule primitive crashes the VM if compiled for 64 bit. I had intended to push the fixes for 64-bit FFI as a VM team initiative, but it's a complex set of changes that require coordination of VMMaker (oscog plus traditional), as well as of all the platforms (oscog, trunk, all platforms) so IMO this would be a lot to take on right now. But I guess that I should ask - is there interest in implementing fixes for 64-bit FFI? Some background: Mantis report and patches to implement the fixes, circa 2008. I assume some bit rot will have set in by this time: <http://bugs.squeak.org/view.php?id=7237> Status of the fixes, as tested on various platforms: <http://lists.squeakfoundation.org/pipermail/vm-dev/2008-May/001945.html> The last discussion relative to VM team priorities: <http://lists.squeakfoundation.org/pipermail/vm-dev/2009-July/002853.html> Dave

July 24, 2011