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

Re: [Pharo-project] Standard input in Pharo?

by Sean P. DeNigris

Guillermo Polito wrote > > Thanks for fixing :) > Sure! For fun, here's a REPL using no packages added to 1.4: [ command := FileStream stdin nextLine. command = 'exit' ] whileFalse: [ result := Compiler evaluate: command. FileStream stdout nextPutAll: result asString; lf ]. You just have to start from a terminal... Sean -- View this message in context: http://forum.world.st/Standard-input-in-Pharo-tp2173080p4610033.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

Re: [Pharo-project] OSProcess - is process done?

by Igor Stasenko

On 5 May 2012 00:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> >> PipeableOSProcess>>#upToEnd eventually calls >> AttachableFileStream>>#upToEnd, which tries to perform a buffered read by >> "self nextInto: 1000" (which eventually calls primitiveFileRead which >> calls sqFileReadIntoAt which calls fread with count arg of 1000). >> > > After further investigation, it seems to me that blocking #upToEnd is > functionally the same as #upToEndOfFile, because its test to stop reading > data is StandardFileStream>>atEnd, which calls feof(). Therefore, if there > is no EOF, it will keep reading until the pipe is out of data, and then hang > in fread on the following iteration. > imo stdin upToEnd makes no sense.. one should not expect that data which comes to stdin has any notion of "end", therefore he should never use this method on such stream. stdin/out are unbound (endless) streams , and use things like eof(), and other of such sort should be discouraged.. since it is same as asking infinity atEnd. > -- > View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4609991.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] OSProcess - is process done?

by Sean P. DeNigris

Sean P. DeNigris wrote > > PipeableOSProcess>>#upToEnd eventually calls > AttachableFileStream>>#upToEnd, which tries to perform a buffered read by > "self nextInto: 1000" (which eventually calls primitiveFileRead which > calls sqFileReadIntoAt which calls fread with count arg of 1000). > After further investigation, it seems to me that blocking #upToEnd is functionally the same as #upToEndOfFile, because its test to stop reading data is StandardFileStream>>atEnd, which calls feof(). Therefore, if there is no EOF, it will keep reading until the pipe is out of data, and then hang in fread on the following iteration. -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4609991.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

Re: [Pharo-project] Drawing speed for animations?

by Igor Stasenko

On 4 May 2012 23:23, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > On Friday, 4. May 2012 18:01:47 Igor Stasenko wrote: > >> hard to say.. apparently every morph should be drawn only once per step. >> probably you mixing stepping and drawing/updating? >> >> during stepping you should change some state, like advance the >> counters, do some calculations etc.. >> and then _just_ invalidate morphs which need to be redrawn, but do not >> draw them directly. > > Except for a few lines I don't draw anything myself. I just intercepted > drawOn: in myMorphs so I could count the calls. Assuming each Morph is drawn > once Â per step, the counts I get are plausible and I see that don't get > redraws for morphs which are invisible. > > I just don't know if 0.2 msec for drawing a single morph is as good as its > gets. It is several hundred thousand CPU cycles per Morph. Even when you > assume 100 pixels per Morph, it is still a few thousand clock cycles for a > single pixel. > may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex? you know, there's always workarounds.. like in case of particles, instead of creating separate morphs for each of them, just use single morph and draw them in own #drawOn: method for morph which will represents your scene.. what i meant to say, that you don't have to stick with morphic , if you there some heavy number-crunching, or a lot of drawings per frame. > I made another test, where I just move 100 Morphs inside a Rectangle around. I > got comparable speed, i.e. morphic was not always able to catch up with the > screen refresh rate. In this case the movement was a lot faster when there was > nothing else on the screen, when it moved over a Browser it slowed down quite > a bit, which is understandable. My scrolling thingy however does not move > across the whole screen, so morphic should have a bit less work. > > Invalidating: > > Do I invalide the Morph itself or its parent? If a Morph moves, the space it > occupied before the move has to be redrawn too. Or do I invalidate it before > and after the move? > i think if you using right method's to change morph's position, it should handle it automatically, so you don't have to worry about it by yourself. (see Morph>>position:) > @Hilaire > >>And what about using PasteUpMorph with an unique step in the message >>taking care of the update of the submorphs? > > What would be the advantage of doing this? Doesn't the "World" take care of > updates well enough? > > -- > Martin > -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] FileReference convenience

by Sean P. DeNigris

Guillermo Polito wrote > > as an extension method should be fine :P. > Right, forgot to mention that part ;-) Package it with whatever class is responsible for filing in (which right now are the streams). -- View this message in context: http://forum.world.st/FileReference-convenience-tp4609828p4609955.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

[Pharo-project] Slint in Pharo 1.4 / Nautilus?

by Francois Stephany

Hi, I do not have a clue how to load Slint in Pharo 1.4. Is there something to use it with Nautilus (altough, I dont really need a GUI)? Cheers, Francois

May 4, 2012

Re: [Pharo-project] Traits depending on RIng

by Guillermo Polito

On Fri, May 4, 2012 at 11:28 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. We were discussing in > http://code.google.com/p/pharo/issues/detail?id=5748 > The thing is that Traits are depenending on Ring. And I don't really like > that. If you do a simple #addToComposition: you end up calling Ring. > > The problematic method is: > > TraitDescription >> #collectMethodsFor: aSelector into: methodDescription > > (self includesSelector: aSelector) ifTrue: [ > methodDescription addLocatedMethod: ( > RGMethodDefinition > realClass: self > selector: aSelector)] > > > which uses RGMethodDefinition. > > Previously (before Ring) it was using LocatedMethod (which was removed) > > collectMethodsFor: aSelector into: methodDescription > (self includesSelector: aSelector) ifTrue: [ > methodDescription addLocatedMethod: ( > LocatedMethod > location: self > selector: aSelector)] > > > I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that > you can see all the stack. > > This is the reason why FuelPackageLoader depends on Ring, just for the > traits when we do the #addToComposition:. > > So...what do we do? we just accept the depedency? > Why not use a CompiledMethod instead? More on, the TraitMethodDescription already knows the selector, so storing only the behaviors containing related methods should be enough... > > cheers > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 4, 2012

Re: [Pharo-project] Traits depending on RIng

by Mariano Martinez Peck

here is the log On Fri, May 4, 2012 at 11:28 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. We were discussing in > http://code.google.com/p/pharo/issues/detail?id=5748 > The thing is that Traits are depenending on Ring. And I don't really like > that. If you do a simple #addToComposition: you end up calling Ring. > > The problematic method is: > > TraitDescription >> #collectMethodsFor: aSelector into: methodDescription > > (self includesSelector: aSelector) ifTrue: [ > methodDescription addLocatedMethod: ( > RGMethodDefinition > realClass: self > selector: aSelector)] > > > which uses RGMethodDefinition. > > Previously (before Ring) it was using LocatedMethod (which was removed) > > collectMethodsFor: aSelector into: methodDescription > (self includesSelector: aSelector) ifTrue: [ > methodDescription addLocatedMethod: ( > LocatedMethod > location: self > selector: aSelector)] > > > I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that > you can see all the stack. > > This is the reason why FuelPackageLoader depends on Ring, just for the > traits when we do the #addToComposition:. > > So...what do we do? we just accept the depedency? > > cheers > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 4, 2012

[Pharo-project] Traits depending on RIng

by Mariano Martinez Peck

Hi guys. We were discussing in http://code.google.com/p/pharo/issues/detail?id=5748 The thing is that Traits are depenending on Ring. And I don't really like that. If you do a simple #addToComposition: you end up calling Ring. The problematic method is: TraitDescription >> #collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( RGMethodDefinition realClass: self selector: aSelector)] which uses RGMethodDefinition. Previously (before Ring) it was using LocatedMethod (which was removed) collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( LocatedMethod location: self selector: aSelector)] I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that you can see all the stack. This is the reason why FuelPackageLoader depends on Ring, just for the traits when we do the #addToComposition:. So...what do we do? we just accept the depedency? cheers -- Mariano http://marianopeck.wordpress.com

May 4, 2012

Re: [Pharo-project] Drawing speed for animations?

by Martin Drautzburg

On Friday, 4. May 2012 18:01:47 Igor Stasenko wrote: > hard to say.. apparently every morph should be drawn only once per step. > probably you mixing stepping and drawing/updating? > > during stepping you should change some state, like advance the > counters, do some calculations etc.. > and then _just_ invalidate morphs which need to be redrawn, but do not > draw them directly. Except for a few lines I don't draw anything myself. I just intercepted drawOn: in myMorphs so I could count the calls. Assuming each Morph is drawn once per step, the counts I get are plausible and I see that don't get redraws for morphs which are invisible. I just don't know if 0.2 msec for drawing a single morph is as good as its gets. It is several hundred thousand CPU cycles per Morph. Even when you assume 100 pixels per Morph, it is still a few thousand clock cycles for a single pixel. I made another test, where I just move 100 Morphs inside a Rectangle around. I got comparable speed, i.e. morphic was not always able to catch up with the screen refresh rate. In this case the movement was a lot faster when there was nothing else on the screen, when it moved over a Browser it slowed down quite a bit, which is understandable. My scrolling thingy however does not move across the whole screen, so morphic should have a bit less work. Invalidating: Do I invalide the Morph itself or its parent? If a Morph moves, the space it occupied before the move has to be redrawn too. Or do I invalidate it before and after the move? @Hilaire >And what about using PasteUpMorph with an unique step in the message >taking care of the update of the submorphs? What would be the advantage of doing this? Doesn't the "World" take care of updates well enough? -- Martin

May 4, 2012