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

[Pharo-project] Quasi-stateful traits?
by Stan Shepherd Feb. 27, 2010

Feb. 27, 2010

To test out the possibilities of using traits for refactoring, I had a go at rationalising OmniBrowser/OmniBrowser2. This showed up that it appears to be possible to use the current traits implementation in a 'quasi-stateful' manner. that is, you can directly address the variables of a trait's 'hosting' class. This is rather contrary to my previous understanding of stateless traits. Is this normal behaviour? I've written up the details here. http://neat-sheet.com/development-blog.html/ ...Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571120.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 15

[Pharo-project] [ANN] Printed version of "Dynamic Web Development with Seaside"
by Lukas Renggli Feb. 27, 2010

Feb. 27, 2010

A print-on-demand, softcover copy of the book "Dynamic Web Development with Seaside" is available from Lulu. The printed book is identical with the online and the PDF version of the book. http://book.seaside.st/book/introduction/print-book We wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk, GemStone Smalltalk and Instantiations for generously sponsoring this book. Please distribute this message widely. Cheers, Stef & Lukas

1 0

[Pharo-project] Issue 329: strange behaviour when Proceeding or Stepping in a newly opened Debugger
by StÃ©phane Ducasse Feb. 27, 2010

Feb. 27, 2010

http://code.google.com/p/pharo/issues/detail?id=329 what is the status? Can we make progress on this point? Stef Reported by jfitzell, Nov 11, 2008 Summary ~~~~~~~ When you Proceed in a Debugger, it assumes the interruptedProcess is sitting at the right context and so merely resumes the process. This assumption is valid once you have hit Restart or recompiled a method but not (currently) when the Debugger is first opened. When the Debugger first opens, the interruptedProcess is sitting in Process>>suspend and that is within the contexts of all the UnhandledError handling code, the code to open the debugger, etc. So if you hit Proceed right after opening the Debugger, the behaviour is different (see below). Current Behaviour ~~~~~~~~~~~~~~~~~ If you evaluate "Error signal" and then immediately Proceed, the behaviour is as follows: + Debugger class>>openOn:context:label:contents:fullView: is resumed and runs to completion, falling off the end + UnhandledError>>defaultAction eventually returns (and returns a Process because of the weird implementation of StandardToolSet>>debugError:) + The (non-resumable) UnhandledError is resumed with that value (a Process) + This causes the signal of UnhandledError in Error>>defaultAction to return the Process + Error>>defaultAction now returns but it ignores the Process that was returned by the UnhandledError and just returns self + The (possibly non-resumable) original error is now resumed with the value of #defaultAction (self) Expected Behaviour ~~~~~~~~~~~~~~~~~~ While the above basically works, the return value (the Error) is pretty sub-optimal and it is logically a bit confusing because the Debugger is supposed to be debugging the context where the error was signaled, not the code path that led to opening the Debugger. When you press Step, you expect it to make one step withing the current context, not to unwind a whole bunch of error handling code first. I expect step to simply make a step in the signaling context and I expect Proceed to carry on running in the signaling context. Since we are dealing with an Error that did not have a default value (since #defaultValue resulted in opening a Debugger), it seems reasonable to return nil as the result of the signal. Reproducing the Problem ~~~~~~~~~~~~~~~~~~~~~~~ This is of course hard to trace. You can verify the return value by simply inspecting "Error signal" and then hitting Proceed in the Debugger that pops up. You will see the result is an Error, not nil as I would expect. (For comparison, VW produces nil in this case, though you have to "Debug" and then "Run" because it won't let you Proceed a non-resumable error). To confirm the execution path, I ended up adding Transcript messages in UndefinedObject>>handleSignal: like this: handleSignal: exception value := exception defaultAction. Transcript show: exception name; show: ' -- defaultAction returned value: '; show: value printString; cr. ^ exception resumeUnchecked: value Suggested Fix ~~~~~~~~~~~~~ As far as I can tell, the best/easiest fix is to have the Debugger set the process into the debugged context on startup. I did this by making the attached change to Debugger>>process:controller:context:isolationHead:. It just adds a call of #popTo:value: on the process. (the debugger doesn't seem to be in a Monticello package?) This exception stuff gets complicated though, so discussion may be warranted if anybody else has a better suggestion. ***As an aside, I think the return values in UnhandledError>>defaultAction and StandardToolSet>>debugError: should be fixed to be more meaningful (or self). Returning a Process as the result of either message is silly. Debugger-processcontrollercontextisolationHead.st 704 bytes Download Delete commentComment 1 by jfitzell, Nov 11, 2008 Sorry... don't know why I couldn't see the Tools package. I found it and saved a version into Pharo-Inbox: Name: Tools-jf.90 Author: jf Time: 11 November 2008, 2:52:23 pm UUID: 5b6889f2-9071-314b-9c30-e6d83e014049 Ancestors: Tools-stephane.ducasse.89 Possible fix for issue 329: http://code.google.com/p/pharo/issues/detail?id=329 When opening a Debugger, pop the interruptedProcess back to the context that signaled the original Error. Delete commentComment 2 by jfitzell, Nov 11, 2008 Gah! Just discovered my fix seems to break things when a Warning is triggered... I need to look into it further. Delete commentComment 3 by jfitzell, Nov 11, 2008 Ok, the error I was getting was "the active process cannot pop contexts". The problem seems to be fixed by implementing ToolSet>>debugContext:label:contents: as follows: debugContext: aContext label: aString contents: contents ^ self debug: Processor activeProcess context: aContext label: aString contents: contents fullView: false This also has the side-benefit that "[Warning signal: 'foo'] fork" will now work (you get a white screen of death without that change). Anybody know why the Debugger class-side methods #openOn:context:label:contents:fullView: and #openContext:label:contents: are implemented differently to begin with? The method names don't suggest that their behaviour should be different. I feel like I've pulled on a thread that maybe I shouldn't have pulled on... :) Delete commentComment 4 by jfitzell, Nov 11, 2008 And I notice DebuggerUnwindBug>>testUnwindDebuggerWithStep is failing, but it seems to fail even with my changes reverted so I think that's not a problem here. Delete commentComment 5 by marcus.denker, Feb 18, 2009 As the change seems to be not stable yet, I have attached the mcz to the bug-report (this way we can clean the inbox) Tools-jf.90.mcz 384 KB Download

1 0

[Pharo-project] self halt
by Hilaire Fernandes Feb. 27, 2010

Feb. 27, 2010

On a updated pharo 1.1 image, a "self halt" block the image. The debugger is raised but the UI is frozen.

2 2

[Pharo-project] [update 1.1] #11235
by Marcus Denker Feb. 27, 2010

Feb. 27, 2010

11235 -------- - Issue 2057: Clean Codeloader more... - Issue 2029: Undeclared Variables - Issue 1922: use #forceNewFileNamed:do: pattern -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 1

[Pharo-project] [update 1.1] #11235
by Marcus Denker Feb. 27, 2010

Feb. 27, 2010

11235 --------- - Issue 1628: Error: There is no free space in this set!. - Enh Diff tool -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]
by Miguel Enrique CobÃ¡ Martinez Feb. 27, 2010

Feb. 27, 2010

This can be useful too. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

2 1

Feb. 27, 2010

... testserver, where are you?

5 8

[Pharo-project] Scamper revival
by Torsten Bergmann Feb. 26, 2010

Feb. 26, 2010

Nice. If this is cleaned up we can use it in the help system. Thx T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

[Pharo-project] Few more words about Xtreams
by Igor Stasenko Feb. 26, 2010

Feb. 26, 2010

a) A BufferedXtream can be implemented ultimately as a wrapper stream, so any stream can be buffered , using Xtream>>buffered ^ self buffered: self preferredBufferSize Xtream>>buffered: aBufferSize ^ (self wrapWith: BufferedXtream) bufferSize: aBufferSize Xtream>>preferredBufferSize ^ 1024 I think there should be an abstract WrapperXtream, from which you can inherit various kinds of wrappers, like buffering, conversion etc etc. b) An ascii/binary mode should be deprecated. The rationale is: generic streams, as well as Collections can't say anything about nature of elements they working with. It could be anyting, like stream of collections, or stream of arbitrary objects. Introducing modes at such basic level implying that all streams should support either of them, and adding unwanted limiting factors and complexity. Its not a problem for more specific streams (like file/socket based ones) to implement these modes (or any other modes) in more robust manner. But i strongly suggesting to not introduce any modes in base class(es). Moreover, a different streams, potentially could support many various modes they like (compressed, encrypted etc etc). Marking out ascii/binary modes seems like a discrimination. But, for backwards compatibility, we could use wrappers to support these modes: Xtream>>ascii ^ self wrapWith: AsciiWrapper AsciiWrapper>>ascii ^ self and by analogy: Xtream>>binary ^ self wrapWith: BinaryWrapper BinaryWrapper>>binary ^ self this gives us a freedom for any streams to not care about supporting these modes explicitly, and in case if they care, they could implement these messages differently. c) species. A use of #contentsSpecies again, introducing a limiting factor, suggesting that all stream elements is going to be of same kind which could be put into special collection, which can hold only elements of specific kind like ByteArray or String. This message used primarily in conjunction with #readInto:startingAt:count: and #next:putAll:startingAt: for batch reads/writes which heavily depending on passing right collection type (you can't pass OrderedCollection or Set ;). My own preference is not _asking_ stream (or collection) for species of its element, but tell it to allocate the buffer (collection) of the kind it prefers , with given size. I.e. instead of: myBuffer := stream contentsSpecies ofSize: 1000. use: myBuffer := stream allocateBufferOfSize: 1000. Then, in most cases, you (as user) would never want to know the species of elements for a stream, and should not care about allocating them and knowing their class! This is one of the patterns i found more flexible and trying to stick with it everywhere i can. Instead of using: someClass := object fooClass. and then, somewhere use: thing := someClass new. i using: thing := object newThing. Because, by answering a class, you losing a control of the creation and proper initialization of these instances and by putting this responsibility onto user, obviously you opening a space for errors. A simple example, suppose you want to build a tree. As usual, you giving the user a way to create new nodes, by exposing the class he should use to create them: TreeNode>>nodeClass ^ TreeNode now, a user, to create a subnode should do things like: newNode := node nodeClass new. newNode parent: node. While, if you just give a simple #newChild TreeNode>>newChild ^ self class new parent: self then, user won't care about proper initialization and write just: newNode := node newChild. which is more concise, not requires to use intermediate value (node class) and much more error safe. -- Best regards, Igor Stasenko AKA sig.

1 0