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

[Pharo-project] [regression reporter]regression occurred
by no-reply＠ci.inria.fr May 9, 2013

May 9, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

1 0

[Pharo-project] [update 3.0] #30116
by Marcus Denker May 9, 2013

May 9, 2013

30116 ----- 10540 Move most methods in CompiledMethod category debuggersupport to DebuggerMethodMap https://pharo.fogbugz.com/f/cases/10540 10037 drag-drop DNU https://pharo.fogbugz.com/f/cases/10037 10575 Cleanup System-Changes a little https://pharo.fogbugz.com/f/cases/10575 10566 Nautilus method icons are not properly cached https://pharo.fogbugz.com/f/cases/10566 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1111.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Changes-MarcusDenker.2… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.461.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1438.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Display Objects-MarcusDenker.108.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CompilerTests-MarcusDenker.14… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.446.diff

1 0

[Pharo-project] Fwd: Sockstream vs ZnSocketStream
by Luc Fabresse May 9, 2013

May 9, 2013

I wrongly sent to the other ML. Luc ---------- Forwarded message ---------- From: Luc Fabresse <luc.fabresse(a)gmail.com> Date: 2013/5/9 Subject: Sockstream vs ZnSocketStream To: A friendly place where any question about pharo is welcome < pharo-users(a)lists.gforge.inria.fr> Hi all, I am *experimenting* with the replacement of the current network layer with OCEAN. My current plan is to make Zinc tests green while working on the top of OCEAN. And investigate the removal of all the current Network classes (does it play?). After looking at Zinc code, there are few dependencies. Basically, I implemented an OCNSOcketStream (inheriting from SocketStream) and redefined some methods of ZnNetworkingUtils. It seems to play so far (green tests). But then, I discovered that Zodiac introduces a new SocketStream hierarchy (ZdcAbstractSocketStream). Now remember the mails of Sven. So my questions are: 1) Is the intent of ZdcSocketStream to be a future replacement for SocketStream? 2) why ZnNetworkingUtils>>initialize makes use of SocketStream instead of ZdcSocketStream? why the code isn't something like that: ZnNetworkingUtils>>initialize super initialize. self socketStreamClass: (Smalltalk globals at: #ZdcSocketStream ifAbsent: [ SocketStream ]) . self secureSocketStreamClass: (Smalltalk globals at: #ZdcSecureSocketStream ifAbsent: [ nil ]) Moreover, I guess that ZdcSocketStream should speed up things (it says optimized version in the name of the superclass ;-)). So probably, my OCNSOcketStream should better inherit from ZdcSocketStream. Thanks for giving me some light here, Luc

1 0

[Pharo-project] [regression reporter]regression occurred
by no-reply＠ci.inria.fr May 9, 2013

May 9, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

1 0

[Pharo-project] [regression reporter]regression occurred
by no-reply＠ci.inria.fr May 9, 2013

May 9, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

1 0

[Pharo-project] [regression reporter]regression occurred
by no-reply＠ci.inria.fr May 9, 2013

May 9, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

1 0

[Pharo-project] [update 3.0] #30115
by Marcus Denker May 9, 2013

May 9, 2013

30115 ----- 10577 deprecate all decompiler API but #decompileMethod: https://pharo.fogbugz.com/f/cases/10577 10581 MenuMorph hardcode bounds instead of using defaultBounds https://pharo.fogbugz.com/f/cases/10581 10579 Small cleanup DebugContext https://pharo.fogbugz.com/f/cases/10579 10574 remove class side methods VirtualMachine https://pharo.fogbugz.com/f/cases/10574 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-MarcusDenker.1426.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.31… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.445.diff

1 0

May 9, 2013

I'm copy Pharo1.0 from Squeaksource to smalltalkhub and for some packages I got error because I do not really know why Transcript does not understand classSide. It looks to be in the MCStWriter. Now I do not get why MCStWriter would have to be called to push a package from my local disc to smalltalkhub. It looks to me fundamentally wrong. May be this is the definition of Gofer of push that is bogus for what I'm doing. May be this is not storing a version but copying a file that I should do. |go repo|repo := MCSmalltalkhubRepository owner: 'Pharo' project: 'Pharo10' user: 'StephaneDucasse' password: 'sn00py_papa'. go := Gofer new. go repository: repo. (((FileSystem disk workingDirectory / 'package-cache') allFiles select: [:each |'*.mcz' match: each basename]) groupedBy: [:each | (each base copyUpToLast: $-) ]) keys do: [:name | go package: name; push. ]

1 0

May 9, 2013

look interesting Begin forwarded message: > From: Steffen MÃ¤rcker <merkste(a)web.de> > Subject: [vwnc] Reducers in Smalltalk > Date: May 9, 2013 4:40:15 PM GMT+02:00 > To: vwnc <vwnc(a)cs.uiuc.edu> > > Hi, > > out of curiosity I did an initial port of Clojure's Reducers library. I've just pushed it to the public repository. It is by no means complete or optimized. In fact, I ask you for your impressions and ideas where to go from here. > > So, what's in here? > Reducers builds upon the simple abstraction that a collection is a reducible object, i.e., an object that understands #reduce:init:. It provides fundamental collection operations similar to classical methods, e.g., like #collect:, but offers specific advantages: > - Reducers are composable and reusable. > - Memory efficiency, since no intermediate collections are constructed. > - Enable collection operations on custom types simply by implementing #reduce:init:. > - Possibility of parallel operations on collections, e.g., with Polycephaly 2. > > For example, the sum of odd numbers could be computed like this: > > | col red | > col := (1 to: 10**6). > (Reducer filter: #odd from: col) reduce: #+ init: 0. > > "composition of reducers works like this:" > red := (Reducer filter: #odd) <> (Reducer map: #squared). > (red from: col) reduce: #+ init: 0. > > Some questions: > 1. What do you think of the current API? > 2. How could one improve the execution time? (Optimizations to the construction of the (nested) blocks?) > > Have fun! > Steffen > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

1 0

[Pharo-project] ci.pharo.org forward working again
by Marcus Denker May 9, 2013

May 9, 2013

The ci.pharo.org forward working again: http://ci.pharo.org Marcus

1 0