January 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Failed to write image file (disk full?)

by StÃ©phane Ducasse

> At seemingly random times I get the error message "Failed to write > image file (disk full?)" when saving an image. My disk is certainly > not full, there are over 200 GB free. It does not seem to be directly > related to Pharo, it happens randomly with the latest Pharo images, > with early Pharo images and even 3.9 images. The annoying thing is > that the image on the disk ends up cropped to about 5 MB. Of course > such a cropped image cannot be opened anymore. As a workaround I found > that if I save the image while the VM is still open under a new name > it works again. This is really strange. I never got that kind of behavior but I used 3.8.18 > I suspect that this is a problem of the Mac VM I am using? I was using > 3.8.20beta1U for a while now, but now I am back at 3.8.19beta2U. > However the exactly same problem happens on that version of the VM. I > think I have to go further back and try 3.8.18beta4U. > > > I know that Philippe encounters these random problems as well. > > Any ideas? Any other experience reports? > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 14, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Igor Stasenko

2009/1/14 Marcus Denker <denker(a)iam.unibe.ch>: > > On 13.01.2009, at 15:51, Igor Stasenko wrote: > >> 2009/1/13 Marcus Denker <denker(a)iam.unibe.ch>: >>> >>> On 09.01.2009, at 16:19, StÃ©phane Ducasse wrote: >>> >>>> one of the point about breakpoint is that they should not get the >>>> method dirty. >>>> I know that some breakpoint code has been harvested but I do not >>>> remember how >>>> to use it. >>>> >>> >>> >>> There is a very simple breakpoint mechanism in Pharo (in Squeak, too, >>> but >>> it was a bit broken there). >>> >>> To try: There is a "toggle break on entry" item in the menu of >>> methods >>> in the >>> old browser. >>> >>> Technically, this just recompiles the method with a call to #break at >>> the beginning. >>> >> >> is it better than doing a trick with method dictionary, as i showed >> in example? > > I did not check your example... but it sounds that it is at least as > good. Maybe the > source-manipulation was done to later support breakpoint anywhere in > the code (not only > the beginning) well, i don't see a need in inruding into a source code anyway. For breaking in the middle of method, one can do following: - intercept entry to a method (in a way like i doing) - step bytecodes manually and break if IP equal to designated value where breakpoint is set. similar to what debugger does, if i'm not mistaken. A more easy to implement could be a breakpoints like 'break at seding a message #xxxx from given method' this can be done by replacing selector #xxxx in given method with special #breakHerePlease and implement #breakHerePlease method properly. > > Marcus > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by Marcus Denker

On 13.01.2009, at 15:51, Igor Stasenko wrote: > 2009/1/13 Marcus Denker <denker(a)iam.unibe.ch>: >> >> On 09.01.2009, at 16:19, StÃ©phane Ducasse wrote: >> >>> one of the point about breakpoint is that they should not get the >>> method dirty. >>> I know that some breakpoint code has been harvested but I do not >>> remember how >>> to use it. >>> >> >> >> There is a very simple breakpoint mechanism in Pharo (in Squeak, too, >> but >> it was a bit broken there). >> >> To try: There is a "toggle break on entry" item in the menu of >> methods >> in the >> old browser. >> >> Technically, this just recompiles the method with a call to #break at >> the beginning. >> > > is it better than doing a trick with method dictionary, as i showed > in example? I did not check your example... but it sounds that it is at least as good. Maybe the source-manipulation was done to later support breakpoint anywhere in the code (not only the beginning) Marcus

Jan. 14, 2009

Re: [Pharo-project] Ecompletion in SuperOB

by David RÃ¶thlisberger

> If I start from a core 10201, and apply updates to 10205, then do: > > ScriptLoader loadSuperOB, and then > ScriptLoader loadEcompletion, Maybe this is because loadSuperOB already loads eCompletion along with extensions to make it work in OB. Probably what happens when you load eCompletion a second time in loadEcompletion is that these extensions get lost, which causes the problem. Just a guess. David > MessageNotUnderstood: TransformationMorph>>x:y: > Proceed > Abandon > Debug > Create > TransformationMorph(Object)>>doesNotUnderstand: #x:y: > ECMenuMorph>>createTitle > ECMenuMorph>>setController:position: > ECMenuMorph class>>controller:position: > ECController>>openMenuFor: > ECController>>handleKeystrokeBefore:editor: > OBTextMorphWithShout(OBTextMorph)>>keyStroke: > OBTextMorphWithShout(TextMorph)>>handleKeystroke: > KeyboardEvent>>sentTo: > OBTextMorphWithShout(Morph)>>handleEvent: > OBTextMorphWithShout(Morph)>>handleFocusEvent: > [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. > ActiveEvent := anEvent. result := focusHolder han...]} > [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} > BlockContext>>on:do: > PasteUpMorph>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendKeyboardEvent: > HandMorph>>handleEvent: > HandMorph>>processEvents > > TransformationMorph(Object)>>doesNotUnderstand: #x:y: > ECMenuMorph>>createTitle > ECMenuMorph>>setController:position: > ECMenuMorph class>>controller:position: > ECController>>openMenuFor: > ECController>>handleKeystrokeBefore:editor: > OBTextMorphWithShout(OBTextMorph)>>keyStroke: > OBTextMorphWithShout(TextMorph)>>handleKeystroke: > KeyboardEvent>>sentTo: > OBTextMorphWithShout(Morph)>>handleEvent: > OBTextMorphWithShout(Morph)>>handleFocusEvent: > [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. > ActiveEvent := anEvent. result := focusHolder han...]} > [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} > BlockContext>>on:do: > PasteUpMorph>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendKeyboardEvent: > HandMorph>>handleEvent: > HandMorph>>processEvents > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2009

[Pharo-project] Failed to write image file (disk full?)

by Lukas Renggli

At seemingly random times I get the error message "Failed to write image file (disk full?)" when saving an image. My disk is certainly not full, there are over 200 GB free. It does not seem to be directly related to Pharo, it happens randomly with the latest Pharo images, with early Pharo images and even 3.9 images. The annoying thing is that the image on the disk ends up cropped to about 5 MB. Of course such a cropped image cannot be opened anymore. As a workaround I found that if I save the image while the VM is still open under a new name it works again. I suspect that this is a problem of the Mac VM I am using? I was using 3.8.20beta1U for a while now, but now I am back at 3.8.19beta2U. However the exactly same problem happens on that version of the VM. I think I have to go further back and try 3.8.18beta4U. I know that Philippe encounters these random problems as well. Any ideas? Any other experience reports? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 14, 2009

Re: [Pharo-project] Ecompletion in SuperOB

by Damien Cassou

On Wed, Jan 14, 2009 at 4:50 AM, Rob Rothwell <r.j.rothwell(a)gmail.com> wrote: > > Ecompletion works fine in a Workspace, but in an OB Code Pane reproducibly > results in the stack trace below. > > Just wanted to let you know in case it has something to do with all the > Morphic clean-up you are doing. It should work with the pharo dev image (newer version of eCompletion I guess). I don't understand why people keep using a core image and install the dev tools manually... I do that already for everyone. -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 14, 2009

[Pharo-project] Ecompletion in SuperOB

by Rob Rothwell

Hello, If I start from a core 10201, and apply updates to 10205, then do: ScriptLoader loadSuperOB, and then ScriptLoader loadEcompletion, Ecompletion works fine in a Workspace, but in an OB Code Pane reproducibly results in the stack trace below. Just wanted to let you know in case it has something to do with all the Morphic clean-up you are doing. Take care, Rob MessageNotUnderstood: TransformationMorph>>x:y: Proceed Abandon Debug Create TransformationMorph(Object)>>doesNotUnderstand: #x:y: ECMenuMorph>>createTitle ECMenuMorph>>setController:position: ECMenuMorph class>>controller:position: ECController>>openMenuFor: ECController>>handleKeystrokeBefore:editor: OBTextMorphWithShout(OBTextMorph)>>keyStroke: OBTextMorphWithShout(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: OBTextMorphWithShout(Morph)>>handleEvent: OBTextMorphWithShout(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents TransformationMorph(Object)>>doesNotUnderstand: #x:y: ECMenuMorph>>createTitle ECMenuMorph>>setController:position: ECMenuMorph class>>controller:position: ECController>>openMenuFor: ECController>>handleKeystrokeBefore:editor: OBTextMorphWithShout(OBTextMorph)>>keyStroke: OBTextMorphWithShout(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: OBTextMorphWithShout(Morph)>>handleEvent: OBTextMorphWithShout(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents

Jan. 14, 2009

Re: [Pharo-project] [ANN][Dev-Images] January 2000 versions

by Bill Schwab

Damien, all, Very impressive! I am looking forward to the new parser and a few other things, but the results are speaking for themselves. One cosmetic detail is that OB and Vistary (and even SoftSqueak) are not nearly as happy as OB and Watery 2. I notice it most in the buttons, especially those "in" the source pane. Gary, thinking ahead some (ok, a LOT), to deployed desktop apps, have you given any thought to how one would create an alignment morph (or whatever you recommend) maximized in the world to allow the non-client parts of the host window to take over as the title bar and friends? Or, are you expecting us to move to a way to allow individual host windows? At some point, I would want to create what amounts to an SDI app. Currently, the feel is essentially MDI. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Jan. 14, 2009

Re: [Pharo-project] [ANN] 10205

by Michael Rueger

On Tue, Jan 13, 2009 at 10:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Because it loads one package after the other. >> Usually the right load order fixes the problem, but in this case loading >> stops working because crucial classes go missing during loading. >> > which only shows that code stinks and need further refactorings to > avoid heavy package interdependencies. > don't blame the tool :) In this case it is a problem with how MC treats a class move. If you load the package first that now includes the class, loading the other removes the class from the system. Loading the packages the way round works. After loading the first package the class is missing, then added by the other package the class was moved to. Unfortunately in this case the missing classes are needed for loading packages so you are stuck. Michael

Jan. 13, 2009

Re: [Pharo-project] [ANN] 10205

by Igor Stasenko

2009/1/13 Michael Rueger <m.rueger(a)acm.org>: > Keith Hodges wrote: >> Michael Rueger wrote: > >> I dont see that the following follows. >>> "and thus needs to be loaded from a configuration map." >>> >> Option 1, Atomic loading. Available in MC1.5/6 as an option that can be >> enabled. > > hmm, we don't have MC 1.5 in Pharo yet, or did I miss that? > >>> I tried loadTogether:merge: but that still ends up with classes missing >>> in the image. >>> >> Might be worth finding out why. > > Because it loads one package after the other. > Usually the right load order fixes the problem, but in this case loading > stops working because crucial classes go missing during loading. > which only shows that code stinks and need further refactorings to avoid heavy package interdependencies. don't blame the tool :) > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2009