- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3919 in pharo: Pckage System-Pools needs to be removed
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: Accepted Owner: marcus.d...@gmail.com New issue 3919 by marcus.d...@gmail.com: Pckage System-Pools needs to be removed http://code.google.com/p/pharo/issues/detail?id=3919 Pckage System-Pools needs to be removed it is empty

1 1

[Pharo-project] Issue 3932 in pharo: Delete package: FreeTypeSubPixelAntiAliasing
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: Accepted Owner: marcus.d...@gmail.com New issue 3932 by marcus.d...@gmail.com: Delete package: FreeTypeSubPixelAntiAliasing http://code.google.com/p/pharo/issues/detail?id=3932 Package FreeTypeSubPixelAntiAliasing is empty. Delete

1 1

[Pharo-project] Issue 3904 in pharo: The Deprecated11 package should be unloaded in 1.3
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: FixProposed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3904 by marcus.d...@gmail.com: The Deprecated11 package should be unloaded in 1.3 http://code.google.com/p/pharo/issues/detail?id=3904 The Deprecated11 package should be unloaded

1 1

[Pharo-project] [update 1.3] #13126
by Marcus Denker April 1, 2011

April 1, 2011

13126 ----- Issue 3677: A to:do: loop cannot modify the limit inside the block Issue 3930: PickAFileToWriteNotification is not used --> move to Deprecated13 Issue 3929: Package Filter for MC based repo browser Issue 3918: Package ST80 needs to be cleaned Issue 3904: The Deprecated11 package should be unloaded in 1.3 Issue 3932: Delete package: FreeTypeSubPixelAntiAliasing Issue 3919: Pckage System-Pools needs to be removed -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3918 in pharo: Package ST80 needs to be cleaned
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: Accepted Owner: marcus.d...@gmail.com New issue 3918 by marcus.d...@gmail.com: Package ST80 needs to be cleaned http://code.google.com/p/pharo/issues/detail?id=3918 Package ST80 needs to be cleaned There are just extension methods left.

1 2

[Pharo-project] ZeroMQ bindings for Pharo
by Vijay Mathew April 1, 2011

April 1, 2011

Hi all, I have started working on ZeroMQ bindings for Pharo. (ZeroMQ website: http://www.zeromq.org/) Thanks, -- Vijay

6 6

[Pharo-project] Issue 3930 in pharo: PickAFileToWriteNotification is not used --> move to Deprecated13
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: Accepted Owner: marcus.d...@gmail.com New issue 3930 by marcus.d...@gmail.com: PickAFileToWriteNotification is not used --> move to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=3930 PickAFileToWriteNotification is not used --> move to Deprecated13

1 1

[Pharo-project] Issue 3677 in pharo: A to:do: loop cannot modify the limit inside the block
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Status: FixedWaitingToBePharoed Owner: stephane...@gmail.com Labels: Milestone-1.3 Type-Squeak New issue 3677 by stephane...@gmail.com: A to:do: loop cannot modify the limit inside the block http://code.google.com/p/pharo/issues/detail?id=3677 Nicolas Cellier uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-nice.184.mcz ==================== Summary ==================== Name: Compiler-nice.184 Author: nice Time: 12 January 2011, 10:09:27.038 pm UUID: ba12fb9c-6c57-429b-b415-1188e1faba8b Ancestors: Compiler-nice.183 Fix DecompilerTests>>#testDecompileLoopWithMovingLimit A to:do: loop cannot modify the limit inside the block =============== Diff against Compiler-nice.183 =============== Item was changed: ----- Method: MessageNode>>toDoFromWhileWithInit: (in category 'macro transformations') ----- toDoFromWhileWithInit: initStmt "Return nil, or a to:do: expression equivalent to this whileTrue:" | variable increment limit toDoBlock body test | (selector key == #whileTrue: and: [initStmt isAssignmentNode and: [initStmt variable isTemp]]) ifFalse: [^nil]. body := arguments last statements. variable := initStmt variable. increment := body last toDoIncrement: variable. (increment == nil or: [receiver statements size ~= 1]) ifTrue: [^nil]. test := receiver statements first. "Note: test chould really be checked that <= or >= comparison jibes with the sign of the (constant) increment" (test isMessageNode and: [(limit := test toDoLimit: variable) notNil]) ifFalse: [^nil]. + "The block must not overwrite the limit" + (limit isVariableNode and: [body anySatisfy: [:e | e isAssignmentNode and: [e variable = limit]]]) + ifTrue: [^nil]. toDoBlock := BlockNode statements: body allButLast returns: false. toDoBlock arguments: (Array with: variable). variable scope: -1. variable beBlockArg. ^MessageNode new receiver: initStmt value selector: (SelectorNode new key: #to:by:do: code: #macro) arguments: (Array with: limit with: increment with: toDoBlock) precedence: precedence!

1 2

Re: [Pharo-project] Issue 432 in pharo: CollectionExtensions
by pharo＠googlecode.com April 1, 2011

April 1, 2011

Updates: Status: Closed Comment #16 on issue 432 by marcus.d...@gmail.com: CollectionExtensions http://code.google.com/p/pharo/issues/detail?id=432 I added to the wishlist: http://code.google.com/p/pharo/wiki/IdeasToImplement "evaluate extension of moose for inclusions in pharo base library"

1 0

[Pharo-project] Regarding SimpleMorphic
by Torsten Bergmann April 1, 2011

April 1, 2011

>> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > For me, this hierarchy is bad. > Workspace is not a model, it's a view basically. Take care not to confuse things here. If you think as "Workspace" as the window that is popping up when you open a workspace then you are on the wrong track. What you see is just one (morphic) view on a model/workspace instance. Workspace, Inspector, Browser - all these ARE models and you can have different looking views on it or open one or more views on the same model. Try |browserModel | browserModel := Browser new. Browser openBrowserView: (browserModel openEditString: nil) label: 'View 1'. Browser openBrowserView: (browserModel openEditString: nil) label: 'View 2'. Evaluate it, show the windows side by side and then click in one: two views on the same model and the changes are propagated to all dependent views. So they ARE MODELS: Take a browser for example. It should know about which class is selected, which methods to display, ... it's a code holder and manager thing. Nothing more ... it doesnt even need a UI. But it's "view parts" could be (one or more) real windows layouted in either morphic or a view in Squeaks old MVC or browser on a Seaside webpage (actually Seaside really has an HTML based browser). The browser model does for instance care if you are working on the instance or class side (see #metaClassIndicated and senders) - but it doesnt care if you switch either using buttons or radio buttons or whatever ... thats up to the view/presentation layer. In general you should be able to also drive this model without ever really having to open a view ... So that even the tools are models (although most people think of them as windows) is a major difference in Smalltalk's UI design compared to most UI frameworks in other languages. VisualWorks uses a special class ApplicationModel to subclass for tools and application windows to make this more clear. Java's Swing (written by people who designed VisualWorks UI first) has a similar but more excessive model design JButton -> ButtonModel, ... The other extreme is VB6/Delphi where you dont have a model at all and have to write an own if you want separation ;) Nothing said about the code quality of the current implementation in Pharo... Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

4 7