March 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] ExternalDropHandler depending on World

by Guillermo Polito

Hi! What is external drop handler? Â¿an object in charge of handling the drag n drop in the paste up morph? Should these two methods depending on Form and World be packaged with Morphic? Guille ExternalDropHandler class>>defaultImageHandler ^ExternalDropHandler type: 'image/' extension: nil action: [:stream :pasteUp :event | | image sketch | stream binary. image := Form fromBinaryStream: ((RWBinaryOrTextStream with: stream contents) reset). sketch := World drawingClass withForm: image. pasteUp addMorph: sketch centeredNear: event position. image := sketch := nil] ExternalDropHandler class>>registerStandardExternalDropHandlers "ExternalDropHandler registerStandardExternalDropHandlers" self registeredHandlers add: ( ExternalDropHandler type: 'image/' extension: nil action: [:stream :pasteUp :event | pasteUp addMorph: (World drawingClass withForm: (Form fromBinaryStream: stream binary)) centeredNear: event position])

March 14, 2012

[Pharo-project] Issue 5476: File Browser "Invalid utf8 input detected" when clicking on a binary file

by Alexis Parseghian

Clicking on a file in the File Browser immediately loads a preview of its contents. Works fine for text files, but when the file is binary (eg .image, .png) the above error is raised. Changeset attached in the issue, wrapping on:do: handler around contents-reading calls. The fix as provided is really basic, just to catch the error and display some kind of warning in the file browser itself. Actual proper handling should probably be more refined. http://code.google.com/p/pharo/issues/detail?id=5476

March 14, 2012

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 5 - Still unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 14, 2012

[Pharo-project] we should make some noise around the pharo conf :)

by stephane ducasse

http://pharoconference.eventbrite.com/ Stef

March 14, 2012

[Pharo-project] Fwd: [Moose-dev] Moose Windows VM problem

by StÃ©phane Ducasse

Hi guys can we fix the one click on windows especially? Stef Begin forwarded message: > From: Usman Bhatti <usman.bhatti(a)gmail.com> > Subject: [Moose-dev] Moose Windows VM problem > Date: March 13, 2012 6:23:44 PM GMT+01:00 > To: Moose-related development <moose-dev(a)iam.unibe.ch> > Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> > > Hello, > > I have a one-click moose image downloaded around first week of Feb 2012. The problem with the image is that it's windows vm that does not launch the image file. In fact, when I execute the vm, it creates a process (visible in windows task manager) but nothing happens. We tried to debug it with Igor but we couldn't (as there is no entry point). The image in the bundle can be launched with latest windows vm (from pharo server) [meaning that the problem comes from the vm which we cannot debug]. > > I downloaded another moose image today and executed its windows vm, and its working fine. > > It would be good to have a jenkins process to run moose on windows vm. Do we have such a setup? If not, I can create one in the coming weeks. > > thanx, > usman > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

March 14, 2012

[Pharo-project] TestCase>>#assert:equals: optimization

by Stefan Marr

Hi: While stepping through bytecodes, I noticed a bit annoying inefficiency in the SUnit implementation. The description string in #assert:equals: is always computed, even if it is not necessary. While that might not be a performance problem, I find it rather distracting when I have to debug on the bytecode/VM level. Since there seem to be only 127 senders or so in the image, you will probably not notice a big performance gain. But in case you care, the change to compute the string only when necessary is below. Best regards Stefan !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:41'! assert: aBooleanOrBlock description: aStringOrBlock aBooleanOrBlock value ifFalse: [ | aString | aString := aStringOrBlock value. self logFailure: aString. TestResult failure signal: aString] ! ! !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! assert: aBooleanOrBlock description: aStringOrBlock resumable: resumableBoolean | exception | aBooleanOrBlock value ifFalse: [|aString| aString := aStringOrBlock value. self logFailure: aString. exception := resumableBoolean ifTrue: [TestResult resumableFailure] ifFalse: [TestResult failure]. exception signal: aString] ! ! !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! assert: expected equals: actual ^ self assert: (expected = actual) description: [self comparingStringBetween: actual and: expected] ! ! -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 13, 2012

[Pharo-project] Extending SystemBrowser

by Ezequiel Lamonica

Hi everybody, I have some problems to extend the SystemBrowser. I want to add a panel at the left of package panel to list products. Product is a new concept that I created to manage a group of packages. For example, Pharo is a product and Seaside is another that depends on Pharo. This is the path that I want to follow: Products -> Packages -> Classes -> Protocols -> Methods I know in Pharo 1.4 the systemBrowser will be changed but I have a proof of concept early and I have to show something working integrated in Pharo 1.3 image. What could I do to start? Any advice?

March 13, 2012

Re: [Pharo-project] [squeak-dev] Simulation discrepancy with #return:

by Eliot Miranda

Hi Yoshiki, Hi Hans-Martin, Hi All, On Tue, Mar 13, 2012 at 10:25 AM, Yoshiki Ohshima <Yoshiki.Ohshima(a)acm.org>wrote: > At Tue, 13 Mar 2012 10:08:12 -0700, > Eliot Miranda wrote: > > > > In this case runUntilErrorOrReturnFrom: aContext should return the > sender of the activation of Foo>test and the result to be returned (42). > But instead it answers the activation of Foo>test > > and nil. Hence the return in ContextPart>return: isn't simulated and > control passes to the next statement, ^666. > > > > Once again I'm drawn into the bowels of runUntilErrorOrReturnFrom: > > :) It is my nemesis. > > This seems close to the realm of magic to me. Thank you for looking > into it! > Alas, I find it near to magic too. I understand what's going on. The terminateTo: call in resume: doesn't trip the unwind-protect in runUntilErrorOrReturnFrom: (as it shouldn't; terminateTo: specifically doesn't run unwinds by design). So runUntilErrorOrReturnFrom: doesn't answer the right context to resume. It answers Foo>test instead of Foo>test's sender. What I don't understand is what is a valid criterion for determining these cases. I can hack the method, special casing it for ContextPart>return: and ContextPart>resume:, but that's not acceptable. So if anyone has the desire to pair on this let me know. Perhaps we could have a go at it over skype sometime soon (not today; already blown a lot of time looking at this ;) ). In any case I've attached two versions of runUntilErrorOrReturnFrom:, one instrumented, one not, containing a hack that gets the right answer (in this case). Yoshiki, you might play with the uninstrumented one to get you going. Hans-Martin, I think you're one of very few people who could shed light on this. To use the instrumented one (which prints its arguments and halts between evaluation and deciding what to return) step the debugger up to e.g. the send of return:, inspect thisContext (the context about to be sent return:) and set ContextPart's class var QuickStep to that context (in the inspector evaluate QuickStep := self). Then do step. At least the hack doesn't make things worse; the tests appear the same. So one thing to do is to play with the hack, ad see if it causes problems. Another thing to do is to think about the criterion in the hacked runUntilErrorOrReturnFrom: when one should return from the receiver's receiver, rather from aSender's sender. I'm cc'ing the Pharo list. Here's Yoshiki's original message and a substantive reply of mine: On Tue, Mar 13, 2012 at 3:27 AM, Yoshiki Ohshima <Yoshiki.Ohshima(a)acm.org> wrote: > Hello, > I noticed that step executing the following code in debugger yields > different results: > ------------------- > test > 3 < 4 ifTrue: [ > thisContext return: 42]. > ^ 666. > ------------------- > In the normal execution, you get 42 as expected, but if you debug it > and step execute, #return: does not actually return and you get 666. > It appears that the primitive for #terminateTo: is the culprit... -- Yoshiki On Tue, Mar 13, 2012 at 10:08 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Yoshiki, >From what I can see so far it is the return value from runUntilErrorOrReturnFrom: in complete: when the debugger executes test's return: call. i.e. the debugged process is in Foo>>test at pc 43: 37 <22> pushConstant: 3 38 <23> pushConstant: 4 39 <B2> send: < 40 <9B> jumpFalse: 45 41 <89> pushThisContext: 42 <21> pushConstant: 42 43 <E0> send: return: 44 <87> pop 45 <24> pushConstant: 666 46 <7C> returnTop The stack in the debugger is Process>>complete: Process>>completeStep: Debugger>>doStep and Process>complete: is complete: aContext "Run self until aContext is popped or an unhandled error is raised. Return self's new top context, unless an unhandled error was raised then return the signaler context (rather than open a debugger)." | ctxt pair error | ctxt := suspendedContext. suspendedContext := nil. "disable this process while running its stack in active process below" pair := ctxt runUntilErrorOrReturnFrom: aContext. suspendedContext := pair first. error := pair second. error ifNotNil: [^ error signalerContext]. ^ suspendedContext where the receiver is the activation of Foo>test, and aContext is the activation of ContextPart>return: (whose receiver is also the receiver of complete:, the activation of Foo>test). In this case runUntilErrorOrReturnFrom: aContext should return the sender of the activation of Foo>test and the result to be returned (42). But instead it answers the activation of Foo>test and nil. Hence the return in ContextPart>return: isn't simulated and control passes to the next statement, ^666. Once again I'm drawn into the bowels of runUntilErrorOrReturnFrom: :) It is my nemesis. -- best, Eliot -- best, Eliot

March 13, 2012

Re: [Pharo-project] Finally, jenkins were able to build win32 VM.

by Tudor Girba

Strange. I tried to reproduce the problem, but following the same path worked fine the second time. Doru On Tue, Mar 13, 2012 at 3:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Ah, I forgot to mention: the same scenario works with the VM from Eliot (2522) > > Cheers, > Doru > > On Tue, Mar 13, 2012 at 3:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I just tried it and it crashed :(. >> >> Here is what I did: >> - I took the Moose image >> - it started fine, and seem to be responsive >> - I then loaded code in it using a configuration >> - while loading, it crashed >> >> I attach here the crash.dmp file. I cannot provide the actual code >> because it is proprietary. I will try to reproduce the problem in more >> available settings. >> >> Cheers, >> Doru >> >> >> On Tue, Mar 13, 2012 at 8:54 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>Thanks Igor. >>>>Guys can you try and report if you have problems? >>> >>> Yes, thanks Igor, >>> >>> How can I see if this release integrates Eliots latest >>> fixes for Cog? >>> >>> Thx >>> T. >>> -- >>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- www.tudorgirba.com "Every thing has its own flow"

March 13, 2012

Re: [Pharo-project] Finally, jenkins were able to build win32 VM.

by Tudor Girba

Ah, I forgot to mention: the same scenario works with the VM from Eliot (2522) Cheers, Doru On Tue, Mar 13, 2012 at 3:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I just tried it and it crashed :(. > > Here is what I did: > - I took the Moose image > - it started fine, and seem to be responsive > - I then loaded code in it using a configuration > - while loading, it crashed > > I attach here the crash.dmp file. I cannot provide the actual code > because it is proprietary. I will try to reproduce the problem in more > available settings. > > Cheers, > Doru > > > On Tue, Mar 13, 2012 at 8:54 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>Thanks Igor. >>>Guys can you try and report if you have problems? >> >> Yes, thanks Igor, >> >> How can I see if this release integrates Eliots latest >> fixes for Cog? >> >> Thx >> T. >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- www.tudorgirba.com "Every thing has its own flow"

March 13, 2012