December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?
by Sven Van Caekenberghe Dec. 9, 2010

Dec. 9, 2010

Related to the Matrix CSV input/output optimalization quest, I was puzzled why writing seemed so much slower than reading. Here is a simple example: [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream print: 100 atRandom; space ] ] ] timeToRun. 1558 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ Integer readFrom: stream. stream peekFor: $ ] ] ] timeToRun. 183 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream nextPut: ($a to: $z) atRandom; space ] ] ] timeToRun. 1705 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream next. stream peekFor: $ ] ] ] timeToRun. 47 Clearly, the writing is close to an order of magnitude slower than reading. This was on Pharo 1.1 with Cog, but I double-checked with Pharo 1.2 and Squeak 4.1. On my machine (Mac Book Pro), this is what another dynamic language does: > (time (with-output-to-file (out "/tmp/numbers.txt") (loop repeat 100000 do (format out "~d " (random 100))))) Timing the evaluation of (WITH-OUTPUT-TO-FILE (OUT "/tmp/numbers.txt") (LOOP REPEAT 100000 DO (FORMAT OUT "~d " (RANDOM 100)))) User time = 0.413 System time = 0.002 Elapsed time = 0.401 Allocation = 2502320 bytes 0 Page faults Calls to %EVAL 1700063 NIL > (time (with-open-file (in "/tmp/numbers.txt") (loop repeat 100000 do (read in)))) Timing the evaluation of (WITH-OPEN-FILE (IN "/tmp/numbers.txt") (LOOP REPEAT 100000 DO (READ IN))) User time = 0.328 System time = 0.001 Elapsed time = 0.315 Allocation = 2500764 bytes 0 Page faults Calls to %EVAL 1400056 NIL So Pharo Smalltalk clearly matches the read/parse speed, which is great, but fails at simple writing. Maybe I am doing something wrong here (I know these are MultiByteFileSteams), but I fail to see what. Something with buffering/flushing ? Anybody any idea ? Sven

5 12

[Pharo-project] Issue 3396 in pharo: Change Notification in Monticello Browser is broken
by pharo＠googlecode.com Dec. 9, 2010

Dec. 9, 2010

Status: Accepted Owner: ---- Labels: Type-ReportDefect Milestone-1.2 Importance-High New issue 3396 by renggli: Change Notification in Monticello Browser is broken http://code.google.com/p/pharo/issues/detail?id=3396 Packages are not marked as dirty anymore

1 1

[Pharo-project] need help to fix the test: testEvaluationOfSelfSend
by stephane ducasse Dec. 9, 2010

Dec. 9, 2010

testEvaluationOfSelfSend "Tests the evaluation of an inherited method that uses super send and self send" | result editor | editor := self method asText asMorph editor. result := Compiler new evaluate: (self method copyFrom: 6 to: self method size) in: self model doItContext to: self model doItReceiver notifying: editor ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true. self assert: result = (6250 / 3) Hi guys this test loses me. Can somebody have a look? I probably misses something obvious. Stef

1 0

Re: [Pharo-project] Just another struggling newbie
by Marcus Denker Dec. 9, 2010

Dec. 9, 2010

On Dec 9, 2010, at 3:53 PM, Chip Nowacek wrote: > Hello everyone, > > While I should have introduced myself before I ran into trouble, it is trouble that has brought me here. I guess I'm glad something provided the excuse to meet you. > > First, a short introduction... > > I'm really new to Smalltalk. Kent Beck said it's a good choice for my project. Technically, I come from the database architecture world - though I am more entrepreneur now than techie. I'm starting up a new company and Kent suggested building a prototype myself instead of bringing someone else in - so here I am. I'm trying to move from Squeak because Pharo feels a little more developer oriented. We'll see how it goes. > > To the matter: I don't understand why I can't accept a change to my comment in one of my classes. When I try to accept in the OB Package Browser, about a dozen calls in, #Utility is being sent #changeStamp and doesn't understand it. I am in the midst of sorting through the stack trying to figure out what happened. As you might imagine, it's a little discouraging for such a basic function to blow up. What makes it worse, I'm probably the cause of the problem - I just don't know what I screwed up. I am working in Pharo 1.1.1 and have loaded Magma and O2 per: > Hello, We did not include O2 in the release precisely because it it not yet mature enough... it has lots of nice features and I understand that people want to use it. But man-power was not there to bring it to a state where all these bugs are fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [ANN 1.2beta] pre-build beta#12272
by Marcus Denker Dec. 9, 2010

Dec. 9, 2010

On Dec 9, 2010, at 3:21 PM, Lukas Renggli wrote: > Cool, is there also a fixed URL that I can refer to? > > Sometime like we previously had for stable versions? > Yes: http://www.pharo-project.org/pharo-download/unstable-core but this lags a bit (link update is not yet automatic) Marcus > Lukas > > On 9 December 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> https://gforge.inria.fr/frs/download.php/28042/PharoCore-1.2beta-12272.zip >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model
by pharo＠googlecode.com Dec. 9, 2010

Dec. 9, 2010

Status: Accepted Owner: guillermopolito New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 The accessor should be added to load last version of OCompletion in Core 1.2

5 13

[Pharo-project] [ANN 1.2beta] pre-build beta#12272
by Marcus Denker Dec. 9, 2010

Dec. 9, 2010

https://gforge.inria.fr/frs/download.php/28042/PharoCore-1.2beta-12272.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:
by pharo＠googlecode.com Dec. 9, 2010

Dec. 9, 2010

Status: Accepted Owner: da...(a)teleport.com New issue 3391 by da...(a)teleport.com: BlockClosure>>assertWithDescription: sends #logFailure: http://code.google.com/p/pharo/issues/detail?id=3391 In a PharoCore image (Pharo1.1.1 #11414 or Pharo1.2a #12271) the only sender of #assertWithDescription: is RxMatcher>>split: ... which wouldn't be that bad, except that BlockClosure>>assertWithDescription: sends #logFailure: which is only implemented in TestCase .... Soooo, it appears that assertWithDescription: should only be sent from instances of TestCase (and send removed from RxMatcher>>split:) or the send of #logFailure: removed from BlockClosure>>assertWithDescription: ... Found this on in GemStone testing while trying to figure out a test case that would trigger a failure of #assertWithDescription:, which BTW, I couldn't do .... so the #assertWithDescription: is probably unnecessary (or we need a test case to trigger the assertion)...

1 4

[Pharo-project] [update 1.2] #12273
by Marcus Denker Dec. 9, 2010

Dec. 9, 2010

12273 ----- Issue 3388: Fix some red tests in Pharo1. Issue 3385: TextEditor doest not understand #model Issue 3391: BlockClosure>>assertWithDescription: sends #logFailure: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3388 in pharo: Fix some red tests in Pharo1.2
by pharo＠googlecode.com Dec. 9, 2010

Dec. 9, 2010

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3388 by stephane.ducasse: Fix some red tests in Pharo1.2 http://code.google.com/p/pharo/issues/detail?id=3388 marcus I started to fix some tests. These two ones are ready for inclusion. Attachments: fixingSystemNavigationtests.2.cs 1.3 KB

1 1