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

Re: [Pharo-project] SocketPlugin: ignoring unknown option 'TCP_CORK'

by Philippe Marschall

On 02/13/2012 12:08 AM, Eliot Miranda wrote: > > > > > Hi Phillipe, > > you'll need to add TCP_CORK to the list of known options in > platforms/unix/plugins/SocketPlugin/sqUnixSocket.c Do you accept patches? Is the source still at [1]? [1] http://www.squeakvm.org/svn/squeak/branches/Cog/ Cheers Philippe

Feb. 13, 2012

Re: [Pharo-project] Few Morphic questions/ issues

by S Krish

Will do so after a thorough test/ recheck on code by next weekend.. On Mon, Feb 13, 2012 at 1:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks > > What I suggest is produce some change set with the proposed fixes you have. > Morphic was written before new invoked initialize automatically and to of > places would benefit from that. > Benjamin and alain helped already a lot to improve the situation. > > Stef > > On Feb 12, 2012, at 8:59 PM, S Krish wrote: > > > > > * CheckboxMorph does not implement #defaultBounds or take sensible > defaults. > > > > * PluggableTextFieldMorph defaults to defaulBounds of MorphicModel, > does not hideScrollBars.. both h and v.. ?, in effect is not defaulted to > behave like a single line TextFieldMorph. > > > > * PluggableTextMorph has #defaultBounds of MorphicModel.. prefer a > better bounds of a standard text morpsh typically flatter of 400@300 .. > ?. Unless immediately initiated with #on:text:readSelection:menu, we need > explicitly handling. I would suggest if we can look at initializing for the > morph > > PluggableTextMorph>>initialize > > > > ... > > self setText: ''. > > textMorph bounds: self defaultBounds. > > self acceptOnFocusChange: true. > > ... > > * SystemWindow >> openInWorld: aWorld > > .. > > self bounds: (RealEstateAgent initialFrameFor: self world: aWorld). > > ... > > > > bounds should not be hardcoded.. to full extents. Use a more > sensible flexible approach in all framework classes. > > > > This perhaps a neat comment..! > > > > openAsIsIn: aWorld > > "Sad fixup for dodgy layout." > > > > super openAsIsIn: aWorld. > > self allMorphs do: [:m | m layoutChanged] > > > > * In Pharo 1.3 I do not have OBTextMorphSelection >> #debugIt > > > > * > > > > > > >

Feb. 13, 2012

[Pharo-project] Debugging with Toggle breakpoint

by S Krish

Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly.. I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo. I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation: ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!) On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest : * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window . * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully.. * Mouse inputs become sluggish... * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code.. Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also.. Will dig in deeper and come back.

Feb. 13, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Martin Dias

I think that then this deserves at least a page in the documentation, > right? > > +1 I'll add something. > > -- > Mariano > http://marianopeck.wordpress.com > >

Feb. 13, 2012

Re: [Pharo-project] Maybe someone here can give me an idea on where to start

by Schwab,Wilhelm K

Friedrich, I have been through some of this. I have gotten serial I/O to work well on Windows (non-cog so far); I'm not so sure about Linux in general, or about cog in particular. Most of the hardware I have running Linux is new enough to not have native ports (a regrettable form of "progress" given how many extant devices have serial ports, but that's another thread). USB-serial converters universally suck in my experience, so linux testing has been slow so far. That said, attached are some methods I created to help avoid silent failures; #openPortWKS: will raise an error if the port fails to open. Cog seems to be failing primitives, which is progress in itself. Note that KernelLibrary is OS dependent, and exists because it is a common entry point in Dolphin, meaning I have a lot of code that uses it. I have included it because I thought I saw it somewhere in the code - you might not need it. No warranties, HTH. You might (as Eliot suggests) indeed have to build your own vm with diagnostic information. I had to do so with Ian's vm. I suggest looking at the mapping of port names to numbers and vice versa. Most of my problems were related to that, IIRC, and there was no feedback about what the vm was doing. Sig's idea of bringing such mappig information into the images and hence error descriptions would be most helpful. If nothing else, you should have concrete evidence that the vm is doing the correct things, allowing you to look elsewhere. As it is, we have to hunt for the truth. Again, failling primitives and the logging you have so far are a big step in the right direction. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Sunday, February 12, 2012 6:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Maybe someone here can give me an idea on where to start Hi Friedrich, On Sat, Feb 11, 2012 at 2:02 AM, Friedrich Dominicus <frido(a)q-software-solutions.de<mailto:frido@q-software-solutions.de>> wrote: Well it's a somewhat longer story. I have some code to interface via the serial lines. And I want to do that on Windows and Linux. So far so good. Now my code for interfacing to the serial lines works fine on Windows. But it fails on Linux here's the debug.log from Pharo: THERE_BE_DRAGONS_HERE PrimitiveFailed: primitive #primWritePortByName:from:startingAt:count: in SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) failed 11 February 2012 10:56:40 am VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Image: Pharo1.3 [Latest update: #13320] SerialPort(Object)>>primitiveFailed: Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) Arguments and temporary variables: selector: #primWritePortByName:from:startingAt:count: Receiver's instance variables: port: '/dev/ttyUSB0' baudRate: 9600 stopBitsType: 1 parityType: 0 dataBits: 8 outputFlowControlType: 0 inputFlowControlType: 0 xOnByte: 19 xOffByte: 24 SerialPort(Object)>>primitiveFailed Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) Arguments and temporary variables: Receiver's instance variables: port: '/dev/ttyUSB0' baudRate: 9600 stopBitsType: 1 parityType: 0 dataBits: 8 outputFlowControlType: 0 inputFlowControlType: 0 xOnByte: 19 xOffByte: 24 Where do I start or how do I start to solve this error? You'll need to use gdb to look at the internals of the plugin code. You might also want to build a debug VM to make the debugging easier. Here are two places to start: http://www.squeakvm.org/svn/squeak/branches/Cog/cygwinbuild/HowToBuild http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/HowToBuild There's also Mariano Peck's blog on the VM. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus -- best, Eliot

Feb. 13, 2012

Re: [Pharo-project] Maybe someone here can give me an idea on where to start

by Eliot Miranda

Hi Friedrich, On Sat, Feb 11, 2012 at 2:02 AM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > Well it's a somewhat longer story. I have some code to interface via the > serial lines. And I want to do that on Windows and Linux. So far so > good. Now my code for interfacing to the serial lines works fine on > Windows. But it fails on Linux here's the debug.log from Pharo: > THERE_BE_DRAGONS_HERE > PrimitiveFailed: primitive #primWritePortByName:from:startingAt:count: in > SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) failed > 11 February 2012 10:56:40 am > > VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter > VMMaker.oscog-eem.78] > Image: Pharo1.3 [Latest update: #13320] > > SerialPort(Object)>>primitiveFailed: > Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 > stopbits, no parity) > Arguments and temporary variables: > selector: #primWritePortByName:from:startingAt:count: > Receiver's instance variables: > port: '/dev/ttyUSB0' > baudRate: 9600 > stopBitsType: 1 > parityType: 0 > dataBits: 8 > outputFlowControlType: 0 > inputFlowControlType: 0 > xOnByte: 19 > xOffByte: 24 > > > SerialPort(Object)>>primitiveFailed > Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 > stopbits, no parity) > Arguments and temporary variables: > > Receiver's instance variables: > port: '/dev/ttyUSB0' > baudRate: 9600 > stopBitsType: 1 > parityType: 0 > dataBits: 8 > outputFlowControlType: 0 > inputFlowControlType: 0 > xOnByte: 19 > xOffByte: 24 > > Where do I start or how do I start to solve this error? > You'll need to use gdb to look at the internals of the plugin code. You might also want to build a debug VM to make the debugging easier. Here are two places to start: http://www.squeakvm.org/svn/squeak/branches/Cog/cygwinbuild/HowToBuild http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/HowToBuild There's also Mariano Peck's blog on the VM. > Regards > Friedrich > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > -- best, Eliot

Feb. 12, 2012

Re: [Pharo-project] SocketPlugin: ignoring unknown option 'TCP_CORK'

by Eliot Miranda

Hi Phillipe, you'll need to add TCP_CORK to the list of known options in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c On Sat, Feb 11, 2012 at 1:51 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > I had this crazy idea, what instead of buffering at the application level > I use the native buffer of the socket? I would be doing more or less this: > > set TCP_CORK to 1 > set TCP_NODELAY to 0 > > do individual writes > > set TCP_CORK to 0 > set TCP_NODELAY to 1 > > do last write > > goto 1 > > (use TCP_NOWAIT and TCP_NOPUSH on BSD/MacOS) > > I hacked something together and tried to push it through some benchmarks > but the SocketPlugin was not very impressed: > > SocketPlugin: ignoring unknown option 'TCP_CORK' > > This is on Linux with Cog. > > Cheers > Philippe > > > -- best, Eliot

Feb. 12, 2012

Re: [Pharo-project] aboutToStyle:

by Schwab,Wilhelm K

Something that I have long wanted a clean way to do is to change the background color of text editors. I've gotten close a few times, but it's a bit more of a hack than I care to make. A suitable style option would be appreciated - I have *no* idea how/where to add it. My guess is that it belongs in themes, but that's just a guess. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Alain Plantec [alain.plantec(a)yahoo.com] Sent: Sunday, February 12, 2012 3:34 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] aboutToStyle: could be added but we need also SHMCClassDefinition to make it work. Alain Le 11/02/2012 09:55, StÃ©phane Ducasse a Ã©crit : > Hi guys > > as part of a controlled experience I'm going over all the changes in MC done in squeak since pharo creation and > > I saw that Squeak has > > MCSnapshotBrowser>>aboutToStyle: aStyler > > | classDefinition shouldStyle | > classSelection ifNil: [ ^false ]. > self switchIsComment ifTrue: [ ^false ]. > methodSelection > ifNotNil: [ > classDefinition := items > detect: [:ea | > ea isClassDefinition and: [ ea className = classSelection ] ] > ifNone: [ > (Smalltalk at: classSelection ifAbsent: [ Object ]) asClassDefinition ]. > shouldStyle := true ] > ifNil: [ > classDefinition := nil. > shouldStyle := categorySelection ~= self extensionsCategory ]. > aStyler > environment: self; > classOrMetaClass: (classDefinition ifNotNil: [ > SHMCClassDefinition > classDefinition: classDefinition > items: items > meta: switch = #class ]). > ^shouldStyle > > while Pharo not. > > Could you tell me if this would not be a good idea to integrate it in Pharo :). > > Stef

Feb. 12, 2012

Re: [Pharo-project] aboutToStyle:

by Alain Plantec

could be added but we need also SHMCClassDefinition to make it work. Alain Le 11/02/2012 09:55, StÃ©phane Ducasse a Ã©crit : > Hi guys > > as part of a controlled experience I'm going over all the changes in MC done in squeak since pharo creation and > > I saw that Squeak has > > MCSnapshotBrowser>>aboutToStyle: aStyler > > | classDefinition shouldStyle | > classSelection ifNil: [ ^false ]. > self switchIsComment ifTrue: [ ^false ]. > methodSelection > ifNotNil: [ > classDefinition := items > detect: [:ea | > ea isClassDefinition and: [ ea className = classSelection ] ] > ifNone: [ > (Smalltalk at: classSelection ifAbsent: [ Object ]) asClassDefinition ]. > shouldStyle := true ] > ifNil: [ > classDefinition := nil. > shouldStyle := categorySelection ~= self extensionsCategory ]. > aStyler > environment: self; > classOrMetaClass: (classDefinition ifNotNil: [ > SHMCClassDefinition > classDefinition: classDefinition > items: items > meta: switch = #class ]). > ^shouldStyle > > while Pharo not. > > Could you tell me if this would not be a good idea to integrate it in Pharo :). > > Stef

Feb. 12, 2012

Re: [Pharo-project] Few Morphic questions/ issues

by StÃ©phane Ducasse

Thanks What I suggest is produce some change set with the proposed fixes you have. Morphic was written before new invoked initialize automatically and to of places would benefit from that. Benjamin and alain helped already a lot to improve the situation. Stef On Feb 12, 2012, at 8:59 PM, S Krish wrote: > > * CheckboxMorph does not implement #defaultBounds or take sensible defaults. > > * PluggableTextFieldMorph defaults to defaulBounds of MorphicModel, does not hideScrollBars.. both h and v.. ?, in effect is not defaulted to behave like a single line TextFieldMorph. > > * PluggableTextMorph has #defaultBounds of MorphicModel.. prefer a better bounds of a standard text morpsh typically flatter of 400@300 .. ?. Unless immediately initiated with #on:text:readSelection:menu, we need explicitly handling. I would suggest if we can look at initializing for the morph > PluggableTextMorph>>initialize > > ... > self setText: ''. > textMorph bounds: self defaultBounds. > self acceptOnFocusChange: true. > ... > * SystemWindow >> openInWorld: aWorld > .. > self bounds: (RealEstateAgent initialFrameFor: self world: aWorld). > ... > > bounds should not be hardcoded.. to full extents. Use a more sensible flexible approach in all framework classes. > > This perhaps a neat comment..! > > openAsIsIn: aWorld > "Sad fixup for dodgy layout." > > super openAsIsIn: aWorld. > self allMorphs do: [:m | m layoutChanged] > > * In Pharo 1.3 I do not have OBTextMorphSelection >> #debugIt > > * > >

Feb. 12, 2012