- Pharo-dev - lists.pharo.org

[Pharo-project] Something is wrong with the CI server
by Pavel Krivanek March 15, 2012

March 15, 2012

Hi, is CI server working well? Jobs seem to be at least two times slower and some were running over whole night. I see no problem with the 1.4 image nor VM. -- Pavel

1 0

[Pharo-project] [update 1.4] #14392
by Marcus Denker March 15, 2012

March 15, 2012

14392 ----- Issue 5482: Class copy is broken http://code.google.com/p/pharo/issues/detail?id=5482 Issue 5454: CombinedChar initialization http://code.google.com/p/pharo/issues/detail?id=5454 Issue 4187: ByteTextConverters subclasses tables need to be checked (a.o. ISO88592TextConverter) http://code.google.com/p/pharo/issues/detail?id=4187 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [squeak-dev] Simulation discrepancy with #return:
by Eliot Miranda March 15, 2012

March 15, 2012

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

2 1

[Pharo-project] Gettext package, who?
by Hilaire Fernandes March 14, 2012

March 14, 2012

Who is maintaining the Gettext package? I remember someone volunteer to take over but I forgot who and where. I have a few fixes to get the gettext package working with 1.4, at least the exporter. Hilaire -- Dr. Geo -- http://www.drgeo.eu

1 0

[Pharo-project] [update 1.4] #14391
by Marcus Denker March 14, 2012

March 14, 2012

14391 ----- Issue 5480: Remove a method in PluggableIconListMorph http://code.google.com/p/pharo/issues/detail?id=5480 Issue 5471: extend time for shouldntTakeLong: http://code.google.com/p/pharo/issues/detail?id=5471 Issue 5456: ClassBuilder depends on Text http://code.google.com/p/pharo/issues/detail?id=5456 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14390
by Marcus Denker March 14, 2012

March 14, 2012

14390 ----- I Issue 5473: Auto accept and update lists in MCWorkingCopyBrowser and MCFileRepositoryVersionInspectorBrowser2 http://code.google.com/p/pharo/issues/detail?id=5473 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Are you sending mails because it looks like the list is blocked.
by StÃ©phane Ducasse March 14, 2012

March 14, 2012

1 0

[Pharo-project] Preparing image for deployment [WAS: How to disable development tools on Pharo 1.3]
by Usman Bhatti March 14, 2012

March 14, 2012

Hello all, Esteban, I took up the package for preparing a deployment image and I am testing it.. It works fine for blocking access to the development tools and debugger... I placed the package in the ss3 repo here: http://ss3.gemstone.com/ss/PrepareImageDeployment (you're one of the admins). Two things where I need help: 1. How do we disable the right-click menu (yellow-button menu) in a text editor? 2. While running deployment preparation code, I have a problem with cleaning monticello repositories... there is a KeyNotFound problem with TAddTest .... the process stops at this error. I have tried debugging it but couldn't find any clues; and the blockage of developers tools does not help much... I am attaching a screenshot of the problem, may be somebody has an idea... thanx in advance, usman [image: Inline image 1] On Thu, Feb 2, 2012 at 2:32 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi Noury, > > I packaged what I have. And even create a settings configuration for it > (under "Deployment" category). > Notice that is very hacky and ugly and needs a lot (and I mean A LOT) of > polish... but is a start :) > > see WSSettings class>>#setDeployment: for a start. > > > > > best, > Esteban > > El 02/02/2012, a las 6:40a.m., Noury Bouraqadi escribiÃ³: > > > Hi Esteban, > > > > On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: > > > >> Hi, > >> > >> in fact, what Mariano posted is just a part... disable everything is > complicated, because code is everywhere... I'm collection all of this > changes in a package, to see in advance if it is possible to abstract that. > > > > Thanks Esteban! > > Do you have a version of this package already? > > Otherwise, I'll start packaging what Mariano sent. > > > > > >> Ideally, we should have a preference "Disable Development Mode", or > something like that to allow desktop developers to easily switch... > >> > > Yes. We should have a menu for this. It's part of dev tools. > > It's a shame that this critical feature isn't available yet. > > > > Noury > > > >> best, > >> Esteban > >> > >> El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: > >> > >>> Noury Bouraqadi wrote: > >>>> I remember having seen some time in the past a menu that allows to > shrink the image and disable the world menu. > >>>> But, I can't retrieve any thing related. I don't care about the menu > per se. I'd be happy with a message to send to some object that does the > job. > >>>> > >>>> > >>>> Noury > >>>> -- > >>>> http://twitter.com/#!/NouryBouraqadi > >>>> http://www.kroobe.com/profile/noury > >>>> > >>>> > >>> Squeak 3.9 based, but perhaps something useful... > >>> "Prepare For Application Deployment" > http://squeak.preeminent.org/tut2007/html/205.html > >>> > >>> > >> > >> > > > > Noury > > -- > > http://twitter.com/#!/NouryBouraqadi > > http://www.kroobe.com/profile/noury > > > > > > Afin de contribuer au respect de l'environnement, > > merci de n'imprimer ce courriel qu'en cas de necessite > > > > Please consider the environment before you print > > > > > > > > > > >

2 1

[Pharo-project] Sorry for the spam
by Guillermo Polito March 14, 2012

March 14, 2012

I have still more stuff about weird dependencies, but I'll stop today :) Guille

1 0

[Pharo-project] ExternalDropHandler depending on World
by Guillermo Polito March 14, 2012

March 14, 2012

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])

1 0