- Pharo-dev - lists.pharo.org

[Pharo-project] Cog-Mac-Cocoa + OSProcess problem
by laurent laffont July 26, 2011

July 26, 2011

Hi Esteban, using last built of Cog-Mac-Cocoa VM, my image crashes as soon as it opens because of OSProcess. Works with StackVM 4.0 The image is Pharo1.3 with SmallHarbour (smallharbour.org) loaded. You can download the image from http://lolgzs.free.fr/pharo/SmallHarbourCrash.zip The log: *** Warning: Warning: OSProcess not available or OSProcess plugin not functioning THERE_BE_DRAGONS_HERE MessageNotUnderstood: PipeableOSProcess class>>output 26 July 2011 9:21:12 am VM: Mac OS - intel - 1070 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.96] 21.0 Image: Pharo1.3 [Latest update: #13287] PipeableOSProcess class(Object)>>doesNotUnderstand: #output Receiver: PipeableOSProcess Arguments and temporary variables: aMessage: output exception: MessageNotUnderstood: PipeableOSProcess class>>output resumeValue: nil Receiver's instance variables: superclass: PipeJunction methodDict: a MethodDictionary(#addToErrorPipeline:->(PipeableOSProcess>>#addTo...etc... format: 148 instanceVariables: #('pipeFromError' 'processProxy' 'keepInitialStdOutOpen' 'ke...etc... organization: ('command pipelines - private' addToErrorPipeline: prepareOutputF...etc... subclasses: nil name: #PipeableOSProcess classPool: nil sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'CommandShell-Piping' traitComposition: {} localSelectors: nil UnixProcess>>waitForCommandOutput: Receiver: a UnixProcess with pid nil Arguments and temporary variables: aCommandString: 'openssl passwd -crypt -quiet -noverify "a"' Receiver's instance variables: pid: nil sessionID: nil stdIn: nil stdOut: nil stdErr: nil processAccessor: a UnixOSProcessAccessor on pid nil allMyChildren: a Dictionary() accessProtect: a Semaphore() ppid: nil pthread: nil path: nil programName: nil arguments: nil environment: nil SHSystemLayer>>waitForProcessCommandOutput: Receiver: a SHSystemLayer Arguments and temporary variables: aString: 'openssl passwd -crypt -quiet -noverify "a"' Receiver's instance variables: osProcess: a UnixProcess with pid nil Cheers, Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

1 0

[Pharo-project] pharo ide task force - morphic issues
by Tudor Girba July 25, 2011

July 25, 2011

Hi, Here is a list of Morphic-related issues that would make the work on the Pharo IDE easier. Btw, if you want to join this cool task force, all you have to do is announce yourself and I offer to provide tasks :). === Keymappings should work with Morph instances - Currently, Keymappings define the keys for all instances of a morph class. This is not useful when we want to create new user interfaces. - Nevertheless, it would be great if we could use the same infrastructure both as it is used now for defining image-wise shortcuts and for controlling instance-based mappings === PluggableTextMorph / TextMorph should provide a means to announce the current selection - Currently, to get notified of when the selection changed, we need to create three subclasses (see below). This solution does not work well with other GLMPluggableTextMorph>>textMorphClass ^ GLMTextMorphForEditView GLMTextMorphForEditView>>editorClass ^ GLMSmalltalkEditor GLMSmalltalkEditor>>storeSelectionInParagraph super storeSelectionInParagraph. self morph ifNotNil: [ self morph editView announceSelectionFrom: self startIndex to: self stopIndex - 1 ] === The label of a TabMorph should shrink to fit the space - Right now a tab with a large title will expand the bounds of the tab. - We would need the possibility to limit the size of the title to the size of the contents. Ideally, there should be some abbreviation (with ...) of the title. === MorphTreeMorph should expand the embedded morphs horizontally - Currently, a row in the MorphTreeMorph takes the preferred size of the embedded morph. Instead, it should expand the row horizontally to fill the space. Or at least we should have the option to have it like that - MorphTreeMorph inherits from ScrollPane. I think it would be great to get it inherit from GeneralScrollPane. Or maybe there is a better solution. === In place editing of items in a list morph - It would be great to have the possibility of editing an item in a list morph in place, rather than being forced to open a dialogue === The button icons in Scrollbar and Expander should work with forms defined in UITheme - Currently, the buttons from Scrollbar and Expander create the arrow icons by drawing them directly. This does not work well with the other icons in the theme. - Instead, the Theme should have a means to provide a form for drawing these === A flexible layout - The idea is to offer a mechanism that would enable us to collapse a pane, and have the rest of the panes expand to fill the space - There is a start of an implementation, but we need to integrate this deeper. - See the thread from: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/040408.ht… === Integrate TWM windows grouping mechanism - I know that for it to work, it requires some changesets that need to be filed in. - It would be great if they were integrated :) - See thread: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050116.html Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

4 4

[Pharo-project] A request or suggestion.
by Friedrich Dominicus July 25, 2011

July 25, 2011

I'm still not realyl understanding the pharo Morph stuff. So I just want to ask. Would it be possible/feasable to group windows. E.g I'd have a group of Workspaces a group of Browsers etc. Currently if the windows just pop open it's hard to find a workspace one may be interested. If there would be a group this should be much easier. Regards Friedrich

5 6

[Pharo-project] List of next large actions
by StÃ©phane Ducasse July 25, 2011

July 25, 2011

Hi guys I will be offline or busy with kids for some days and I wanted to make a list of todos for when I want to do something. - Integrate FS - step one add FS packages - step two integrated = use FS - Add RBengine - step one add RBEngine packages - step two (check RPackage changes) - Add OCompletion - Add Ecompletion - Integrate SystemAnnouncer - step one load package - would be cool to convert SystemChangeNotifierTest into tests usable for SystemAnnouncer (even if RPackage has a lot of tests). - step two replace SystemChangeNotifier emission - Integrate Ring - SystemNavigation should use Ring Objects - Replace Source* and MethodReference by Ring Object May be I missed some points but it would be good to have that in 1.4 Stef

2 4

[Pharo-project] Pharo 1.3 Seaside 'client' build ?
by Sven Van Caekenberghe July 25, 2011

July 25, 2011

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' ?

4 3

[Pharo-project] Polymorph validation
by Jeff Gray July 25, 2011

July 25, 2011

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.

2 1

[Pharo-project] Fwd: Re: Profile interpretation
by Hilaire Fernandes July 25, 2011

July 25, 2011

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%24b7i%242(a)dough.gmane.org> <4E2C0131.4040709(a)gmx.de> <j0hi13%2470h%241(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

2 1

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks
by Marcus Denker July 25, 2011

July 25, 2011

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

1 0

Re: [Pharo-project] About the site
by Marcus Denker July 25, 2011

July 25, 2011

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

1 0

Re: [Pharo-project] [squeak-dev] help needed with the new FFI plugin...
by Eliot Miranda July 24, 2011

July 24, 2011

On Fri, Jul 22, 2011 at 9:08 AM, Ricardo Moran <richi.moran(a)gmail.com>wrote: > Yes, indeed. Right now, for most use cases we use the SerialPort class, but > we still have some FFI code for other stuff hanging around. I plan to write > it as a plugin as soon as I have the time. But getting the FFI working on ARM and/or PPC is more effective than writing yet another plugin, no? We can always add security to the FFI (essentially some way of disabling internal calls within the FFI plugin, e.g. based on cryptographic keys to enable it, or whatever). So I really do appeal to people to help me put the effort in here. I can't justify working on the FFI on ARM or PPC in my Cadence Newspeak gig; we're entirely on x86. I /can/ work on the threaded FFI as we need it at Cadence, just as many other people need it. But for me to move the threaded FFI ahead it needs to be on all platforms and that means I need help on the platforms I can't justify working on. So folks, please give serious consideration to putting effort into something that may be a little harder at first but will yield major benefits slightly later. Let's defer gratification :) > Cheers, > RIcho > > > On Fri, Jul 22, 2011 at 10:37 AM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: > >> It's not part of Etoys yet. If its low-level interface indeed requires >> FFI, then that interface would have to be rewritten as plugin for Etoys to >> include it. >> >> - Bert - >> >> On 22.07.2011, at 14:55, karl ramberg wrote: >> >> What about the Physical Etoys project ? >> http://tecnodacta.com.ar/gira/projects/physical-etoys/ >> >> Karl >> >> On Fri, Jul 22, 2011 at 2:20 PM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: >> >>> >>> On 22.07.2011, at 02:10, Eliot Miranda wrote: >>> >>> > >>> > >>> > On Thu, Jul 21, 2011 at 4:57 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> > On 22 July 2011 02:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > > Hi All, >>> > > today I committed the threaded FFI plugin along with the threaded >>> VM and >>> > > hope to be able to support people in doing threaded FFI work on the >>> x86 >>> > > platforms really soon now (Esteban, amongst others, this means you ;) >>> ). >>> > > But to put the image-level code that uses the new FFI plugin into >>> > > production the standard VM needs to be upgraded to not crash with the >>> > > ExternalFunction image changes the new threaded FFI plugin wants. >>> The main >>> > > change is that ExternalFunction changes size, gaining a stackSize >>> inst var >>> > > which is used to tell the FFI plugin how much stack spacer to reserve >>> for >>> > > marshalling (its computed on first use). The best way for this to >>> happen is >>> > > to start using the ThreadedFFIPlugin as the standard plugin in the >>> > > Interpreter VM. The ThreadedFFIPlugin overall is simpler than the old >>> FFI >>> > > plugin (no assembler support code) and better (fully reentrant). But >>> for >>> > > this to happen we may need to implement the platform=specific parts >>> of >>> > > the ThreadedFFIPlugin (still entirely Smalltalk code) for PowerPC and >>> ARM >>> > > (and perhaps others, SPARC??). I understand what has to be done and >>> I can >>> > > explain it to anyone interested in working on the problem, but I >>> don't have >>> > > any hardware with which I can test the results so its pretty >>> pointless my >>> > > doing the work and producing something inevitably broken. So are >>> there >>> > > people out there who would be interested in doing the port to PPC and >>> ARM? >>> > > It means fleshing out the classes >>> > > ThreadedARMFFIPlugin ThreadedFFICalloutStateForARM >>> > > ThreadedPPCBEFFIPlugin ThreadedFFICalloutStateForPPC >>> > > and having a solid understanding of how alloca works to do stack >>> allocation >>> > > and how the ABIs on ARM and PPC pass registers. >>> > > here's hoping there are a few good low-level people who would be >>> interested. >>> > > Let me know. >>> > >>> > I wonder if you find anyone today using these archs, not saying using >>> > squeak/pharo on them + knowing low-level details + wanting to help :) >>> > >>> > Right, chances are thin. But then if no one is interested then the >>> work doesn't need to be done. Bert, you mentioned the other day that PPC >>> was still relevant for etoys. But am I right in thinking etoys never uses >>> the FFI? >>> >>> Right. Etoys should run on both ARM and PPC, but it does not use FFI. >>> >>> - Bert - >>> >>> >>> >>> >> >> >> >> >> >> >> > > > > -- best, Eliot

4 3