June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] untypeable key combination

by Nicolai Hess

Now I think I solved the issue. At least, if you remove a class from the system that defined a keymapping, there is no reference to an obsolete class anymore. background: the keymap registration works in three steps: 1. collect methods with pragma <keymap> 2. build the registration items with one builder-instance (this builder collects the items too). 3. register all of the collected items. my change is at the third step, instead of working on the collection of the builder, I make a copy and remove all items from the builder. That way the builder does not hold a reference to the shortcut items after they went to the registry. nicolai 2015-06-01 22:16 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-06-01 22:06 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> On Sat, May 30, 2015 at 8:20 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> 2015-05-30 16:01 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>> >>>> Nicolai Hess wrote >>>> > I don't fully understand what to change. >>>> >>>> If Spur will be ready for the next release, why don't we just wait... >>>> >>> >>> I would like to better understand what is the problem and I am sure >>> there is some kind of software pattern to prevent this >>> circular reference situation. >>> >> >> Yes, they're called ephemerons. Read the Wikipedia page and the paper. >> They explain things well. http://en.wikipedia.org/wiki/Ephemeron >> > > Yes now I understand why ephemerons can solve this issue. > But what I was thinking of is, maybe we don't need this circular reference > for our keymapping registry, it looks like some the references only > there because we need this information during building the keymap but not > afterwards. > > > > >> >> >>> >>> >>> >>> >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: >>>> http://forum.world.st/untypeable-key-combination-tp4794607p4829511.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>>> >>> >> >> >> -- >> best, >> Eliot >> > >

June 2, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3365 CogVM source as per VMMaker.oscog-eem.1332/r3365 Newspeak Cogit: Fix the regression in implicit receiver sends caused by VMMaker.oscog-eem.1317 (fix to performance regression caused by using XCHG on x86). The implicit receiver cache uses SendNumArgsReg to refer to the cache object. Hence we must use TempReg for genPushRegisterArgsForNumArgs: in this case. So refactor to genPushRegisterArgsForNumArgs:scratchReg:, passing either TempReg or SendNumArgsReg as approprate. -- best, Eliot

June 2, 2015

Re: [Pharo-dev] [Pharo-users] Pharo 4 Image Freeze

by Nicolai Hess

2015-06-01 23:44 GMT+02:00 Craig Johnson <craig(a)hivemind.net>: > Sure thing. > > To see the bug, file the code below into a clean image and run the > example. The when the debugger pops, step over each line in the method. > I'm doing this on a Windows OS. > > Object subclass: #Cooler > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'ImageFreeze'! > > !Cooler methodsFor: 'as yet unclassified' stamp: 'CraigJohnson 6/1/2015 > 23:31'! > runMe > | a | > self halt. > self except. > a := 1.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > Cooler class > instanceVariableNames: ''! > > !Cooler class methodsFor: 'as yet unclassified' stamp: 'CraigJohnson > 6/1/2015 23:16'! > example > self new runMe ! ! > > This worked until pharo 40245 -> it looks like phase4 in issue 11996 <https://pharo.fogbugz.com/default.asp?11996> Wrong exception handler problem introduced this behavior. > > > > On 2015/06/01 11:00 PM, Esteban Lorenzano wrote: > >> wellâ¦ pharo4 is not a beta :) >> weird that no one else reports same bugâ¦ can you give us a way to >> reproduce the problem? Instead telling you which image does not have a >> problem I was not aware, I would like more to give you a bugfix :) >> >> Esteban >> >> On 01 Jun 2015, at 22:31, Craig Johnson <craig(a)hivemind.net> wrote: >>> >>> >>> Hi All, >>> >>> I'm getting tired of Pharo 4 beta freezing. It happens whenever a >>> exception occurs while in the debugger. >>> >>> Funny that I don't remember any of the Pharo 4 development images >>> freezing. >>> >>> Which image can I use that won't do this? >>> >>> Craig >>> >>> >> > >

June 1, 2015

Re: [Pharo-dev] styling in spotter preview broken ?

by Andrei Chis

There is small mistake in the preview as GTSpotterPreviewBrick>>updatePreviewWith: catches Exception and not Error. We also need to make the preview use the exception handled registered with the spotter. On Mon, Jun 1, 2015 at 11:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-06-01 22:45 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> To debug spotter you should first open it in debug mode. The simplest >> solution is to use GTSpotterGlobalShortcut class>>openGlobalSpotterDebug >> > > No, that does not work. If you put a "self haltOnce" in a <spotterPreview> > method, the preview is just empty, no debugger > window (not in "normal" spotter and not in "spotter debug mode"). > > > >> When not in debug mode spotter has an exception handler that captures all >> exceptions and write them to transcript. >> >> I remember we fixed a while back some bugs related to styling caused by >> the fact that styling was done in a background process. >> Though a quick look on the changes introduced in 50064 doesn't reveal >> any style related change that could cause this issue. >> >> >> Cheers, >> Andrei >> >> On Mon, Jun 1, 2015 at 10:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> 2015-06-01 10:55 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> >>>> >>>> 2015-06-01 10:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> Does this happen, too, when you turn off AST based highlighting? >>>>> >>>> >>>> Yes, I think this is an issue on rubric. >>>> >>>> 50064 >>>> 15605 Update Rubric >>>> >>>> >>> Now with a bug report: >>> 15663 <https://pharo.fogbugz.com/default.asp?15663> styling in spotter >>> preview broken >>> >>> I think some changes in rubric are responsible but I am not sure, because >>> I cannot debug spotters preview. >>> ( #haltOnce is cleared without opening the debugger!) >>> >>> >>> >>>> >>>> >>>>> >>>>> >>>>> > On 30 May 2015, at 12:55, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> > >>>>> > since 50064 some methods lost syntaxhighlight when previewed >>>>> > in spotter. >>>>> > This does not happens for all methods (but most of them) and I can >>>>> not see a pattern. >>>>> > Styling is lost on short and or long methods >>>>> >>>>> >>>> >>> >> >

June 1, 2015

Re: [Pharo-dev] styling in spotter preview broken ?

by Nicolai Hess

2015-06-01 22:45 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > To debug spotter you should first open it in debug mode. The simplest > solution is to use GTSpotterGlobalShortcut class>>openGlobalSpotterDebug > No, that does not work. If you put a "self haltOnce" in a <spotterPreview> method, the preview is just empty, no debugger window (not in "normal" spotter and not in "spotter debug mode"). > When not in debug mode spotter has an exception handler that captures all > exceptions and write them to transcript. > > I remember we fixed a while back some bugs related to styling caused by > the fact that styling was done in a background process. > Though a quick look on the changes introduced in 50064 doesn't reveal any > style related change that could cause this issue. > > > Cheers, > Andrei > > On Mon, Jun 1, 2015 at 10:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-06-01 10:55 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> >>> 2015-06-01 10:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> Does this happen, too, when you turn off AST based highlighting? >>>> >>> >>> Yes, I think this is an issue on rubric. >>> >>> 50064 >>> 15605 Update Rubric >>> >>> >> Now with a bug report: >> 15663 <https://pharo.fogbugz.com/default.asp?15663> styling in spotter >> preview broken >> >> I think some changes in rubric are responsible but I am not sure, because >> I cannot debug spotters preview. >> ( #haltOnce is cleared without opening the debugger!) >> >> >> >>> >>> >>>> >>>> >>>> > On 30 May 2015, at 12:55, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> > >>>> > since 50064 some methods lost syntaxhighlight when previewed >>>> > in spotter. >>>> > This does not happens for all methods (but most of them) and I can >>>> not see a pattern. >>>> > Styling is lost on short and or long methods >>>> >>>> >>> >> >

June 1, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3364 CogVM binaries as per VMMaker.oscog-eem.1331/r3364 General: Merge with Pharo (with VMMaker.oscog-EstebanLorenzano.1322). Changes are null to Squeak VM. Pulled in are conditionally compiled changes for directory & file creation (added ceration permissions) and to macro used to read image file (for iPhone). Cogit: Test the outerContext and method for sanity in the machine code closure value primitive(s). Spur must check to fail in the presence of forwarders. To support the primitive provide TstCqR support on x86 (already exists on ARM), and use it to implement genJumpImmediate: et al. Use the new genJumpImmediate: et al in various basic access primitives. Good for a 5%-10% increase in 0 tinyBenchmarks on Spur. Guard access to the inline cache tag in PICs in GC routines by inlineCacheTagsMayBeObjects. Spur: Spur must follow forwarders in machine code before it follows forwarders in stack pages (since stack page parsing examines methods). Further, closed PICs that refer to unmarked objects must be discarded in freeUnmarkedMachineCode. And closedPICRefersToUnmarkedObject: should guard against an immediate selector. -- best, Eliot

June 1, 2015

Re: [Pharo-dev] styling in spotter preview broken ?

by Andrei Chis

To debug spotter you should first open it in debug mode. The simplest solution is to use GTSpotterGlobalShortcut class>>openGlobalSpotterDebug When not in debug mode spotter has an exception handler that captures all exceptions and write them to transcript. I remember we fixed a while back some bugs related to styling caused by the fact that styling was done in a background process. Though a quick look on the changes introduced in 50064 doesn't reveal any style related change that could cause this issue. Cheers, Andrei On Mon, Jun 1, 2015 at 10:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-06-01 10:55 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-06-01 10:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> Does this happen, too, when you turn off AST based highlighting? >>> >> >> Yes, I think this is an issue on rubric. >> >> 50064 >> 15605 Update Rubric >> >> > Now with a bug report: > 15663 <https://pharo.fogbugz.com/default.asp?15663> styling in spotter > preview broken > > I think some changes in rubric are responsible but I am not sure, because > I cannot debug spotters preview. > ( #haltOnce is cleared without opening the debugger!) > > > >> >> >>> >>> >>> > On 30 May 2015, at 12:55, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> > >>> > since 50064 some methods lost syntaxhighlight when previewed >>> > in spotter. >>> > This does not happens for all methods (but most of them) and I can not >>> see a pattern. >>> > Styling is lost on short and or long methods >>> >>> >> >

June 1, 2015

Re: [Pharo-dev] styling in spotter preview broken ?

by Nicolai Hess

2015-06-01 10:55 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-06-01 10:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Does this happen, too, when you turn off AST based highlighting? >> > > Yes, I think this is an issue on rubric. > > 50064 > 15605 Update Rubric > > Now with a bug report: 15663 <https://pharo.fogbugz.com/default.asp?15663> styling in spotter preview broken I think some changes in rubric are responsible but I am not sure, because I cannot debug spotters preview. ( #haltOnce is cleared without opening the debugger!) > > >> >> >> > On 30 May 2015, at 12:55, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > since 50064 some methods lost syntaxhighlight when previewed >> > in spotter. >> > This does not happens for all methods (but most of them) and I can not >> see a pattern. >> > Styling is lost on short and or long methods >> >> >

June 1, 2015

Re: [Pharo-dev] untypeable key combination

by Nicolai Hess

2015-06-01 22:06 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sat, May 30, 2015 at 8:20 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-05-30 16:01 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> Nicolai Hess wrote >>> > I don't fully understand what to change. >>> >>> If Spur will be ready for the next release, why don't we just wait... >>> >> >> I would like to better understand what is the problem and I am sure >> there is some kind of software pattern to prevent this >> circular reference situation. >> > > Yes, they're called ephemerons. Read the Wikipedia page and the paper. > They explain things well. http://en.wikipedia.org/wiki/Ephemeron > Yes now I understand why ephemerons can solve this issue. But what I was thinking of is, maybe we don't need this circular reference for our keymapping registry, it looks like some the references only there because we need this information during building the keymap but not afterwards. > > >> >> >> >> >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/untypeable-key-combination-tp4794607p4829511.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > > > -- > best, > Eliot >

June 1, 2015

Re: [Pharo-dev] untypeable key combination

by Eliot Miranda

On Sat, May 30, 2015 at 8:20 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-05-30 16:01 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Nicolai Hess wrote >> > I don't fully understand what to change. >> >> If Spur will be ready for the next release, why don't we just wait... >> > > I would like to better understand what is the problem and I am sure > there is some kind of software pattern to prevent this > circular reference situation. > Yes, they're called ephemerons. Read the Wikipedia page and the paper. They explain things well. http://en.wikipedia.org/wiki/Ephemeron > > > > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/untypeable-key-combination-tp4794607p4829511.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > -- best, Eliot

June 1, 2015